Harnessing rCOS for Tool Support—The CoCoME Experience - Formal Methods and Hybrid Real-Time Systems - page 91

put get1 get

C1 C2

put1

put1

Fig. 2. Plug Composition

put get

C1 C2

put1

put1

Fig. 3. Hiding after Chaining

put get

C1 C2

put1

put1

Fig. 4. Feedback

2.2 Coordination

From an external point of view, components provide a number of methods, but
do not themselves activate the functionality specified in the contracts; we need
active entities that implement a desired functionality by coordinating the se-
quences of method calls. In general, these active entities do not share the three
features of components [13].
In [6], we introduce processes into rCOS. Like a component, a process has an
interface declaring its own local state variables and methods, and its behavior is
specified by a process contract. Unlike a component that is passively waiting for
a client to call its provided services, a process is active and has its own control on
when to call out to required services or to wait for a call to its provided services.
For such an active process, we cannot have separate contracts for its provided
interface and required interface, because we cannot have separate specifications
of outgoing calls and incoming calls [13]. So a process only has an interface and its
associated contract (or code). For simplicity, but without losing expressiveness,
we assume a process like a Java thread does not provide services and only calls
methods provided by components. Therefore, processes can only communicate
via shared components. Of course, a component can also communicate with
another component via processes, but without knowing the component that it
is communicating with.