Figure 1: Puma robot manipulator with 3-fingered TUM hand in the Checkers player scenario.
Pattern. For guiding software reuse some researchers proposed the method of developing software ``patterns'' . A pattern is a repeated conceptual paradigm which shortens the communication such, that it replaces learning by re-cognition when the pattern is re-encountered. (A good pattern example is the ``Save'' and the ``Save-As'' button, you might find, when you are working with a new graphical document editor. If you instantly perceive the proper meaning of these buttons, you saved the time otherwise required for studying the manual.) A successful pattern allows more rapid understanding by standardization, better solution turn-around times, and thus improves the component's economy.
Object-Oriented Programming (``OOP'') is an important idea of gaining better re-use value for software components (e.g. [3, 8]). An object is a piece of code that owns private data and provides service through methods (=procedures). It is a run-time instance of a class which describes the behavior of a set of alike objects. By the properties inheritance and polymorphism OOP formalizes the idea of a pattern. Furthermore, the concept of encapsulation, providing only procedural access to private resources, promotes easy re-usage. Since the implementation details are hidden behind the published interface, unexpected interferences when integrating components can be significantly reduced.
Context-Oriented Configuration. The abstractor, in building a reusable piece, is solving a whole set of future problems. For instance, most reusable software results from the experience of being an elaborator several times, then having a flash of insight that solves a number of elaborators' problems once and for all. But often there is an inherent solution conflict between the level of abstraction and generality versus the level of suitability for a particular problem context. One way to make a component more powerful is to formulate the desired context and the appropriate behavior in a set of configuration parameters. In order to keep the required communication and learning effort low, methods for efficient and simple usage are important. In cases of larger numbers of context parameters, the proper organization of consistent sets is a significant burden and should be solved in a systematic and convenient way. By hiding information, the (re-)user can focus on the essential parameters for his particular context.
Concurrent Team Development includes the early
sharing of components and is (in certain phases) related with the
problem of integrating also pre-mature and rapidly changing code
versions. From our experience, three items are worth mentioning:
(i) high-level Unix operating systems offer superior (inherent not
only attached) multi-user and network capabilities (tcp/ip,
nfs, amd, remote login, X11, etc.). They provide the solid ground
for sharing distributed resources via standard networks.
Furthermore, numerous, high-quality, standard tools are everywhere
available (e.g. teams of size larger than one might find aid with
the ``Concurrent Version System'', CVS); (ii) strict OO
encapsulation and modularization simplifies ongoing and independent
component development; (iii) run-time encapsulation of application
components using protected invocation.
Protected invocation means, to invoke a component (method call) by a mechanism, that a potential failure does not affect the caller in an uncontrollable way. For instance, memory allocation bugs can exhibit very unpredictable effects.
Migrating Components. In order to allow early integration of complex components, it is extremely valuable to have the opportunity to quickly isolate any application part by secure fire walls. Easy component migration needs support for organizing and re-organizing process and communication structures. Additionally, the program code must be able to use the very same call syntax for local and remote component communication.
Error Messaging Support when Objects Migrate. When software components are used in both, an local and a distributed fashion, the abstractor, the elaborators, and the user need extra support. If it is not available, the programmers get frustrated: what to do with the message in case the call is local or remote? Send to whom and how? Conventional solutions, like sending messages to the standard error channel are unreliable, since they might stay unseen in some other terminal. Therefore, it is very desireable to use a unified and compact exception message generation interfaces, delegating the appropriate handling to the infrastructure.
Summary of Design Issues. We found following points important:
Figure 2: Service Object Request Management Architecture (SORMA ) is a framework and infrastructure to connect to dynamically created Service Objects (SO) via time-optimal intra-process and protected inter-process communication. (Left:) Various software components communicate in four processes running on one or several hosts. (Right:) Local and remote requests to SOs are managed by the SORM and COMM.
Usually, these design goals are considered conflicting. The next section introduces the Service Object Request Management Architecture (``SORMA''), and describes some of the concepts which contribute to solve the above stated goals. For a more detailed account see .