7.1 Pattern Pipe

Motivation

Eine Pipeline besteht aus Komponenten zur Verarbeitung von Daten und aus Komponenten für die Weiterleitung der zu verarbeitenden Daten. Um vom Transportmechanismus abstrahieren zu können, soll dieses Pattern eine Komponente realisieren, welche an einem fest definierten Interface

einen Transportdienst realisiert. Ableitungen von diesem Pattern, Properties oder Erkenntnisse aus dem Kontext können zu verschiedenen Implementierungen der Komponente führen, was die umgebenen Komponenten allerdings in keiner Weise beeinflußt. Der Einsatz dieses Patterns soll es dem Entwerfer erlauben sich auf den Datenfluß eines Systems zu konzentieren.

Structure

Eine Pipe wird zwischen zwei Objekten realisiert, der source und der destination . Dabei wird das Attribut sourceData and das Attribut destData gebunden, siehe dazu auch die folgende Abbildung . Die beiden Objekte sind über eine 1:1-Beziehung miteinander verbunden.

Das dynamische Verhalten der beteiligten Objekte ist ebenfalls in der Abbildung skizziert. Es werden 4 mögliche Realisierungen unterschieden, die auf unterschiedliche Kontexte zurückzuführen sind.

Keine Annahmen über die beteiligten Verarbeitungskomponenten, das Attribute destData wird durch einen indirekten Zugriff auf das Attribute sourceDate realisiert. Es gibt keine Bindungen für push , pull , notify und request .
Die Pipe ist Pull-Driven . Damit realisiert source eine bezüglich dieser Pipe passive Komponente. destination ist aktiv.
Bei dem Objekt source wird die Methode request benutzt. Sie muß von Filter zur Verfügung gestellt werden.
Für das Objekt destination werden die Methoden read und pull implementiert. Die Methode notify muß von Filter realisiert werden.
Die Pipe ist Push-Driven . Damit ist source aktiv und destination realisiert eine bezüglich dieser Pipe passive Komponente.
Bei dem Objekt source wird die Methode push realisiert. Für das Objekt destination wird die Methode read implementiert und die Methode notify benötigt. notify muß von dem Pattern Filter implementiert werden.
Beide beteiligten Verarbeitungskomponenten sind bezüglich dieser Pipe aktiv. Dies entspricht der Kombination der beiden zuletzt genannten Fälle. Zusätzlich müssen nun die Zugriffe durch push und pull synchronisiert werden. Dazu wird ein semaphore innerhalb der Methode read benutzt.

Die letzten drei Fälle ermöglichen zusätzlich die Pufferung der zu übertragenden Daten. Dieser buffer wird realisiert sofern eine Puffergröße bufferSize größer Null spezifiziert wird. Die Aufrufhierarchie der Methoden ist in der Abbildung durch Pfeile dargestellt.

Participants

Objects:

source
Das Quell-Objekt.
destination
Das Ziel-Objekt.

Attributes:

sourceData (use at source)
Das Attribute aus dem die Daten stammen.
destinationData (implement at destination)
Das Attribute in das die Daten wandern.

Relations:

entry (at destination)
Die Relation zur Datenquelle, dem Eingang der Pipe.
exit (at source)
Die Relation zur Datensenke, dem Ausgang der Pipe.

Methods:

read (optional implement at destination)
Liest die Daten von der Quelle und schreibt sie in die Senke. Wird für Push-Active-Pipes benötigt.
push (optional implement at source)
Triggert einen Schreibvorgang von der Quelle in die Pipe.
pull (optional implement at destination)
Triggert einen Lesevorgang aus der Pipe in die Senke.
notify (optional use at destination)
Gibt die Änderung der Daten bei der Quelle bekannt.
request (optional use at source)
Fordert die Aktualisierung der Daten bei der Quelle an.

Properties:

bufferSize
Ist dieser Wert definiert und größer Null, dann wird auf der Ausgangsseite der Pipe ein Puffer mit der angegebenen Größe in Form einer FIFO realisiert.
selectivePipe
Dieser boolsche Wert bestimmt, ob eine SelectivePipe erzeugt werden soll, oder nicht. Die SelectivePipe behebt das in [Kae98] auf Seite 41 beschriebene Problem. Für das betreffende Filter muß selectivePipe ebenfalls definiert werden. selectivePipe ist nur für PullActive-Pipes sinnvoll.
useProxy
Ein Wert source oder destination fordert die Aggregation eines AttributeProxy -Patterns für einen der beiden Objekttypen. Die Implementierung Pipe wird dann auf den Umgang mit den Proxies abgestimmt.

Collaborations

Das Pattern arbeitet eng mit dem Pattern Filter zusammen. Durch Kombination lassen sich aus den beiden Patterns komplexe Pipelines zusamenstellen. Das Pattern Pipe benötigt unter Umständen Implementierungen für die Methoden notify und request durch die drei genannten Patterns. Es stellt diesen Patterns Implementierungen für die Methoden read , push und pull zur Verfügung. Es stellt ein Attribut destData zur Verfügung, welches den Wert des Attributs sourceData wiederspiegelt.

Das Pattern aggregiert je nach Konstellation die Patterns SingleIndirection (obsolete) , MethodAlias , AttributeValue , BufferedValue und AttributeProxy .

Implementation

Gemäß den 4 unterschiedlichen Implementierungen für eine Pipe aggregiert dieses Pattern andere Patterns oder erzeugt Methoden auf der Basis von Code-Templates. Die Variante ohne jegliche Aktivität der benachbarten Objekte kann durch einfache Aggregation des Patterns FollowRelation realisiert werden. Für die Variante Push+Pull-Activity ohne selectivePipe sieht der teilweise aggregierte Code wie folgt aus:

{pull}

"Fordert die Daten bei {source} an. Diese stehen dann in {destData} zur Verfuegung."

(self {entry} instance {request})
    ifTrue: [self {read}].
^ self {destData}

Je nachdem, ob es sich bei der verbindenden Relation um eine 1:1 oder 1:n-Relation handelt, wird die erste, oder die zweite Variante für push erzeugt.

{push}

"Fordert die nachfolgende Verarbeitungskomponente auf, die Daten bei source abzuholen."

^ self {exit} instance {notify}

{push}

"Fordert die nachfolgende Verarbeitungskomponenten auf, die Daten bei source an abzuholen."

^ self {exit} connections collect: [:each | each {notify}]

{read}

"Liest die Daten aus sourceData bei source und stellt sie dann in {destData} zur Verfuegung." 

^ self {semaphore}
critical: [| temp |
    temp := self {entry} instance {sourceData}.
    (temp == self {popDestData})
        ifTrue: [false]
        ifFalse: [self {destData}: temp.
            true]]

Für destData wird je nachdem, ob bufferSize gesetzt ist, oder nicht, das Pattern BufferedValue oder AttributeVariable aggregiert. Im ersten Fall, wird die Bindung für popDestData auf "pop{destData}" gesetzt. Im letzten Fall werden die beiden Bindungen gleichgesetzt. Für semaphore wird ein AttributeVariable aggregiert. Diese Variable wird mit einem Semaphore aus dem Smalltalk-Runtime initialisiert.

PEdit description

Pattern Pipe Category paf
    ObjectType use source
    ObjectType use destination
    Attribute use sourceData at source
    Attribute implement destinationData at destination
    SingleRelation use exit at source
    SingleRelation use entry at destination
    SingleMethod use optional request at source
    SingleMethod implement optional read at destination
    SingleMethod use optional notify at destination
    SingleMethod implement optional pull at destination
    SingleMethod implement optional push at source
    Expression implement preset bufferSize
    Expression implement preset selectivePipe
    Expression implement preset useProxy
End

AG VLSI Design and Architecture

SFB 501 - Project D1: Application System "Buildings"

PSiGene

Pattern Catalog