decoupling.sgml

机器人开源项目orocos的源代码

<emphasis><link linkend="symbolic-term">symbolic</link></emphasis>
nature.
</para>
</listitem>

<listitem>
<para>
<anchor id="mathematical-term">
<emphasis role="strong">Mathematical</emphasis> properties do not show
up as separate <emphasis>method calls</emphasis>, but as the 
<emphasis role="strong">numeric arguments</emphasis> of the physical
and symbolic method calls.
(Of course, there are exceptions, e.g., mathematical algorithms
(linear algebra, solutions of differential equations, etc.) do have
method class names that are of a pure mathematical nature.)
</para>
<para>
The same physical or symbolic property is often described by more than
one <emphasis role="strong">mathematical representation</emphasis>.
For example:
<itemizedlist>

<listitem>
<para>
Reference frames are represented by Denavit-Hartenberg numbers, or by
a homogeneous transformation matrix.
</para>
</listitem>

<listitem>
<para>
The <emphasis>order</emphasis> of the coordinates  in a
coordinate vector is often very arbitrary. For example, each of the
two three-dimensional vectors in the six-dimensional instantaneous
velocity vector (&ldquo;screw&rdquo;) can be placed first or last in a
six-dimensional coordinate vector. This choice influences the
compatibility between software modules that have to interact at the
rigid body velocity level.
</para>
</listitem>

</itemizedlist>
</para>
</listitem>

</itemizedlist>
<emphasis>All</emphasis> classes in a software system should use 
standardized mathematical representations at all times, because such
consistency facilitates integration and maintenance efforts.
The choice of physical units is very important; Orocos adopts the 
<emphasis role="strong">SI units</emphasis> as standard (and should
provide conversion routines to other unit systems).
</para>

</section>


<section id="inter-connection-decoupling">
<title>Inter-connection decoupling (the
<emphasis><link linkend="OPC-pattern">Object-Port-Connector</link></emphasis>
software pattern)</title>
<para>
The above-mentioned example of kinematics and dynamics is just one of
the many engineering areas in which most of the interesting properties
of systems arise from
<emphasis>connecting</emphasis> simpler systems together. For example,
a robot consists of motors, links, joints and grippers, and none of
these components is very useful in itself. The properties of
the individual components are limited, and can easily be encoded in
small-scale library modules. The inter-connection possibilities and
applications, however, are much broader and more difficult to
exhaustively describe and encode in advance. Hence, it is advantageous
to decouple the encoding of the elementary building blocks from the
encoding of their interactions. This document presents the
<anchor id="OPC-pattern">
<emphasis role="strong">Object-Port-Connector software
pattern</emphasis> to achieve this decoupling
(<xref linkend="fig-opc-pattern">):

<figure id="fig-opc-pattern" float="1" pgwide="1">
<title>
 Object-Port-Connector pattern.
</title>
<mediaobject>
<imageobject>
<imagedata fileref="../pictures/opc-pattern.png" format="PNG">
</imageobject>
<imageobject>
<imagedata fileref="../opc-pattern.eps" format="EPS">
</imageobject>
</mediaobject>
</figure>


<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Objects</emphasis> are the &ldquo;building
blocks&rdquo; with which <emphasis>systems</emphasis> can be built.
For example: a rigid body; a revolute joint; a 
linear spring; a torsional damper; etc. Each of these physical Objects
is encoded in (a set of) software class(es), representing 
all symbolic, physical and mathematical properties of the
Object.
</para>
<para>
In addition, a <emphasis>composite Object</emphasis>, such as a robot, can
also act as an elementary Object in a particular context. For example,
for some applications, it suffices to see a robot as nothing more than
an ideal &ldquo;rigid body motion device&rdquo; that executes 3D
motion commands. So, Objects can be composed hierarchically, in the
sense that one Object can internally consist of the inter-connection
of other Objects. In practice, composite Objects are only useful if
their interface remains &ldquo;small&rdquo;, i.e., of the order of
complexity of the interface of elementary Objects.
</para>
</listitem>
<listitem>
<para>
<emphasis role="strong">Ports.</emphasis>
Each Object has several &ldquo;Ports&rdquo; where it can
<emphasis>interact</emphasis> with other Objects. In
kinematics and dynamics, such Ports are often represented by
<emphasis>reference frames</emphasis> on a rigid body, but various
other <emphasis>types</emphasis> of Ports are possible for each
Object.  Each Port has a well-defined set of (symbolic, physical,
mathematical) <emphasis>parameters</emphasis> that are influenced by
the interaction with other Objects. These parameters, of course, can
only be related to properties of the Object to which the Port is
connected.
</para>
</listitem>
<listitem>
<para>
<emphasis role="strong">Connector.</emphasis>
Objects can physically interact with each other in various ways. For
example, two rigid bodies can interact through a revolute joint,
or through an <emphasis>edge-edge</emphasis> contact. Different
connections impose different <emphasis>constraints</emphasis> on the
properties of both connected Objects.  The
<emphasis>connector</emphasis> encodes all the information of the
constraints that the interaction imposes on the connected Objects;
typically, this results in a set of
<emphasis>algebraic constraints</emphasis> on the physical values that
are accessible at the Port objects the Connector is attached to.
</para>
<para>
When the software system is in use, it is easy to find
out the current <emphasis>values</emphasis> of all physical interaction
parameters in the inter-connected system: the Connector is the
<emphasis>unique</emphasis> place where this information must be asked.
For example, the relative velocity of two connected links is to be
found in the revolute joint Connector that links them. The same
Connector knows what force is transmitted through the joint.
</para>
<para>
Although the Connector is the right place <emphasis>to ask</emphasis>
for actual values, it doesn't necessarily have store these values itself.
It does know at which Ports it can find this information,
<emphasis>and</emphasis> it knows whether it must ask the Ports to
update this information with the most recent status of the constraint
encoded in the Connector.
</para>
</listitem>

</itemizedlist>
This Object-Port-Connector pattern has several positive consequences:
<itemizedlist>

<listitem>
<para>
<emphasis role="strong">Smaller interfaces,</emphasis>
because the whole set of properties and functionalities is decoupled in
entities with a much smaller scope: the Object properties, the Port
parameters, and the Connector constraints. In addition, the fact that
the concept (and the corresponding software infrastructure!) is
available to inter-connect elementary functionality into more complex
systems allows to make this flexibility visible at the class interface
level: it's not necessary anymore to define a top-level object
&ldquo;robot&rdquo; with an API that covers all possible kinematic
structures or dynamic interactions, or all possible control laws or
motion planning algorithms. Instead, each particular application has
its own particular API that is the <emphasis>composition</emphasis> of
the APIs of (only) its building blocks.
</para>
<para>
So, in summary, smaller interfaces lead to smaller code libraries,
more focused documentation, easier code maintenance, and easier
incremental development.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Consistency through construction.</emphasis>
Each Connector can only connect Ports of particular types, and those
types prescribe the physical properties of the inter-connection. This
&ldquo;strong typing&rdquo; makes it difficult to construct
inconsistent systems.
</para>
<para>
The potential of consistency-by-construction is only realized
<emphasis>if</emphasis> the software objects that represent an
inter-connected system are indeed <emphasis>constructed</emphasis>
connection by connection, while checked for consistency at the moment
the connection is made.  The software engineering world has, since
long, discovered the usefulness of this approach, and developed the
<emphasis role="strong">Factory</emphasis> software pattern to realize
it: objects are constructed before they are used, according to the
Factory's particular &ldquo;inter-connection&rdquo; schema that
guarantees consistent initialization.
</para>
</listitem>

<listitem>
<para>
<emphasis role="strong">Multi-domain flexibility.</emphasis>
Since the information about any individual physical interaction
between two Objects is managed by a Connector object, it is easy to
add Connectors for interaction between objects of different
<emphasis>physical domains</emphasis>. For example, a motor transforms
electrical energy into mechanical energy; a damper transforms
mechanical energy into thermal energy. Etcetera.
</para>
<para>
In addition, the same principle can be used to connect different
<emphasis>graphical visualisations</emphasis> to a mechanical system
(or any dynamical system, for that matter).
For example, one Connector links a robot link with a 3D CAD model,
while another Connector links the same link to an iconic programming
or monitoring interface.
</para>
</listitem>

</itemizedlist>
The drawback of the Object-Port-Connector pattern is that the
<emphasis>modelling</emphasis> and <emphasis>initialisation</emphasis>
efforts for small-scale systems can be somewhat more involved than in
most existing special-purpose implementations. But this sytematic
approach will avoid many problems when the systems under study become
more complex. 
</para>
<para>
The Object-Port-Connector pattern is also useful to link the symbolic,
physical and mathematical classes of the same object.  The former two
have Ports that connect to (possibly multiple) mathematical objects.
</para>

</section>


<section id="library-decoupling">
<title>Library structure decoupling</title>
<para>
In the process of choosing the most appropriate directory structure
for the software code, one should keep in mind that, in general,
independence between software libraries is maximized if:
<itemizedlist>

<listitem>
<para>
The dependency graph is a <emphasis role="strong">tree</emphasis>, or
a set of non-connected trees: libraries only use functionality from
libraries that are higher up in the tree, or that are in a
disconnected tree.
</para>
</listitem>

<listitem>
<para>
Each library can be understood, developed and maintained by a
<emphasis role="strong"> very small set</emphasis> of people.
</para>
</listitem>

<listitem>
<para>
The implementation of classes in one library doesn't have 
<emphasis role="strong">to know anything</emphasis> about how the
functionality in other libraries is <emphasis>implemented</emphasis>.
(It has to know the interfaces, of course.)
</para>
</listitem>

</itemizedlist>
Hence, it is also easier to &ldquo;spin-off&rdquo; libraries in
stand-alone software projects, as soon as they appeal to a wider
public than that of the project where the library was originally
developed.
</para>

</section>


<section id="object-component-decoupling">
<title>Object-component decoupling</title>

<para>
Object-oriented design is the key approach towards encoding the
functionality of a software system into manageable pieces. Hence,
object-orientation is basically a concern for
&ldquo;programming-in-the-small&rdquo; software
<emphasis>developers</emphasis>, who write code that offers
functionality, as much as possible independently of the application in
which the code is going to be applied.
</para>
<para>
Component-based design, on the other hand, is a key approach to
support the &ldquo;programming-in-the-large&rdquo; 
<emphasis>application builders</emphasis>: they integrate
functionalities of various objects into one particular application,
and add <emphasis>middleware</emphasis> infrastructure such as:
service identity management, access functionality, persistent state
functionality, configuration interfaces, service request interfaces,
etc. 
</para>
<para>
It is worthwhile to decouple the object code from the component
code, because the latter invariably and inherently involves
<emphasis role="strong">application-specific coupling</emphasis>
between software functionalities. 
</para>
<para>
The <ulink url="http://www.omg.org">Object Management Group</ulink>'s
<ulink url="http://www.corba.org">Common Object Request Broker
Architecture (CORBA)</ulink> is a major development in the area of
(vendor, language and platform) neutral programming interfaces for both
Objects and Components.
</para>

</section>


</article>