Singleton (Entwurfsmuster)

Das Singleton (auch Einzelstück genannt) ist ein in der Softwareentwicklung eingesetztes Entwurfsmuster und gehört zur Kategorie der Erzeugungsmuster (engl. Creational Patterns). Es verhindert, dass von einer Klasse mehr als ein Objekt erzeugt werden kann. Dieses Einzelstück ist darüber hinaus üblicherweise global verfügbar. Das Muster ist eines der von der sogenannten Viererbande (GoF) publizierten Muster.

Verwendung

Das Einzelstück findet Verwendung, wenn

• nur ein Objekt zu einer Klasse existieren darf und ein einfacher Zugriff auf dieses Objekt benötigt wird oder
• das einzige Objekt durch Unterklassenbildung spezialisiert werden soll.

Anwendungsbeispiele sind:

• ein zentrales Protokoll-Objekt, das Ausgaben in eine Datei schreibt.
• Druckaufträge, die zu einem Drucker gesendet werden, sollen nur in einen einzigen Puffer geschrieben werden.

UML-Diagramm

Singleton
– instance : Singleton
– Singleton()
+ getInstance() : Singleton

Eigenschaften

Das Einzelstück (Singleton)

• erzeugt und verwaltet das einzige Objekt der Klasse
• bietet globalen Zugriff auf dieses Objekt über eine Instanzoperation (getInstance()).

Dabei ist

• die Instanzoperation eine Klassenmethode, das heißt statisch gebunden
• das private Attribut „Instanz“ (instance) ein Klassenattribut, das heißt ein statisches Attribut.

In Klammern stehen die Bezeichnungen aus obiger Abbildung.

Vorteile

Das Muster bietet eine Verbesserung gegenüber globalen Variablen:

• Zugriffskontrolle kann realisiert werden.
• Das Einzelstück kann durch Unterklassenbildung spezialisiert werden.
• Welche Unterklasse verwendet werden soll, kann zur Laufzeit entschieden werden.
• Die Einzelinstanz muss nur erzeugt werden, wenn sie benötigt wird.
• Sollten später mehrere Objekte benötigt werden, ist eine Änderung leichter möglich als bei globalen Variablen.

Nachteile

• Es besteht die große Gefahr, durch exzessive Verwendung von Singletons quasi ein Äquivalent zu globalen Variablen zu implementieren und damit dann prozedural anstatt objektorientiert zu programmieren.^[1]
• Abhängigkeiten zur Singleton-Klasse werden verschleiert, d. h. ob eine Singleton-Klasse verwendet wird, erschließt sich nicht aus dem Interface einer Klasse, sondern nur anhand der Implementierung.^[2] Zudem wird die Kopplung erhöht, was Wiederverwendbarkeit und Übersichtlichkeit einschränkt.
• Der „Scope“ eines Singletons, also der Bereich, in dem ein Singleton auch wirklich technisch „einzeln“ ist, muss nicht mit dem Bereich zusammenfallen, in dem es „einzeln“ sein soll. Konkret ist bei nebenläufigen oder gar verteilten Systemen schwierig sicherzustellen, dass wirklich nur eine Instanz existiert.
  • Beispielsweise ist in Java eine einfache static-Variable „einzeln je ClassLoader“; in verteilten (zum Beispiel cluster-fähigen) Systemen oder komplexen nebenläufigen Applikationen wie Application-Servern können dadurch wieder mehrere Instanzen nebeneinander existieren.
  • In Systemen mit parallelen Abläufen (Threads) muss sichergestellt sein, dass nicht durch parallele Initialisierung kurzfristig mehr als eine Instanz existiert; und dass das Singleton-Objekt später auch die Verwendung in vielen parallelen Abläufen erlaubt, also threadsicher ist.
  • Werden dynamische Bibliotheken wie DLLs verwendet, muss u. U. sichergestellt werden, dass auch hier nur eine Instanz existieren kann.
• Das Testen eines Singleton kann kompliziert sein. Das Mocken eines Singleton-Objekts ist aufwändig und in manchen Fällen – zum Beispiel, wenn für Testzwecke Fehler erzeugt werden sollen – fast unmöglich. Mit der Java Reflection API ist es jedoch möglich, die Kapselung der Singleton zu verletzen und die Instanziierung zu kontrollieren.^[3]
• Die Konfiguration des Singletons ist – zumindest bei Lazy-Initialization (s. u.) – nur über andere Singletons möglich, zum Beispiel Environment-Variablen, aus einem Registry, aus „well-known“ Files o. Ä.
• Eine Ressource-Deallokation von Ressourcen, die das Singleton verwendet, ist schwierig. So ist zum Beispiel bei einem Singleton für ein Logging-System oft unklar, wann die Logdatei geschlossen werden soll.

Wegen der vielen Nachteile wird das Singleton-Muster (und auch das Idiom Double-checked Locking) mitunter schon als Anti-Pattern bewertet. Für Fälle, wo tatsächlich technisch ein passender Bereich für ein Singleton existiert, können Singletons aber sinnvoll sein – insbesondere wenn sie sich auf andere „einmalige Strukturen“ wie zum Beispiel eine Abstract Factory beziehen. Trotzdem: Das korrekte Design von Singletons ist schwierig – in der Regel schwieriger als Designs ohne Singletons.

Verwendung in der Analyse

In der Analyse wird ein (fachliches) Singleton in der Regel dadurch gekennzeichnet, dass die Multiplizität der Klasse als 1 definiert wird. Wie auch im Design muss der Bereich der Multiplizität hinterfragt werden: Gibt es tatsächlich nur „eine Zentralstelle für …“, oder können zum Beispiel in länderübergreifenden Systemen sehr wohl mehrere Objekte einer Sorte existieren?

Beispiele

Lazy Creation

Von Lazy Creation spricht man, wenn das einzige Objekt der Klasse erst erzeugt wird, wenn es benötigt wird. Ziel ist, dass der Speicherbedarf und die Rechenzeit für die Instanziierung des Objektes nur dann aufgewendet werden, wenn das Objekt wirklich benötigt wird. Hierzu wird der Konstruktor ausschließlich beim ersten Aufruf der Funktion getInstance() aufgerufen.

Implementierung in Java

Die Erstellung des einmalig existierenden Objekts wird folgendermaßen erreicht:

• Der Konstruktor der Singleton-Klasse ist privat. So ist es von außen nicht möglich, ein weiteres Objekt dieser Klasse zu erzeugen.
• Als Ersatz wird eine neue Zugriffsmethode angelegt, die eine Referenz auf das einzige Objekt zurückgeben kann.
• Die Variable, in der das Objekt gespeichert wird, erhält den Modifikator „statisch“ („static“). Sie ist außerdem synchronisiert, um die Sicherheit bei nebenläufiger Ausführung zu gewährleisten. Eine alternative Implementierung, die ohne Synchronisierung auskommt, ist unten unter Eager Creation gezeigt. In Java wird auch dabei das Objekt erst erzeugt, wenn es gebraucht wird.

  public final class Singleton 
  {
      /**
       * Privates Klassenattribut,
       * wird beim erstmaligen Gebrauch (nicht beim Laden) der Klasse erzeugt
       */
      private static Singleton instance;
 
      /** Konstruktor ist privat, Klasse darf nicht von außen instanziiert werden. */
      private Singleton() {}
 
      /**
       * Statische Methode „getInstance()“ liefert die einzige Instanz der Klasse zurück.
       * Ist synchronisiert und somit thread-sicher.
       */
      public synchronized static Singleton getInstance() 
      {
          if (instance == null) 
          {
              instance = new Singleton();
          }
          return instance;
      }
  }

Nachteil dieser Variante ist, dass auch nach der Instanziierung jeder Lesezugriff über getInstance() synchronisiert ist und so mehrere gleichzeitig zugreifende Threads sich gegenseitig blockieren. Implementierungen, die mittels "double-checked locking" bei bereits existierender Instanz auf die Synchronisation verzichten, sind im Allgemeinen nicht threadsicher. ^[4]

Implementierung in C#

ohne Threadsicherheit

  // Nur zur Veranschaulichung – bitte nicht verwenden!
  class Singleton 
  {
 
    private Singleton() { }
    private static Singleton instance = null;
 
    public static Singleton getInstance() 
    {
       if (instance == null) 
       {
          instance = new Singleton();
       }
       return instance;
    }
 
  }
 
  // Zugriff über Singleton s=Singleton.getInstance();

mit Threadsicherheit

  class Singleton 
  {
    private Singleton() { }
    private static volatile Singleton instance;
 
    public static Singleton getInstance() 
    {
       // DoubleLock
       if (instance == null) 
       {
          lock(m_lock) {  
             if (instance == null) 
             { 
                instance = new Singleton();
             }   
          }
       }
       return instance;
    }
 
    // Hilfsfeld für eine sichere Threadsynchronisierung
    private static object m_lock = new object();
  }
 
  // Zugriff über Singleton s=Singleton.getInstance();

Hinweise zum Code:

1. Das private Hilfsobjekt m_lock ist in C# unbedingt notwendig. Die frühere gängige Methode lock(this) {..} hat sich als unzureichend herausgestellt, weil fehlerhafter oder böswilliger Code durch den Aufruf Monitor.Exit(Singleton); die Threadsicherheit einfach aushebeln kann.
2. DoubleLock Methode: Warum zweimal dasselbe if()? Damit nach der Instanziierung des Objektes die bremsende Synchronisation per lock() wegfällt, wird dieselbe if-Abfrage zusätzlich vor dem lock-Abschnitt eingesetzt.
3. Das Schlüsselwort volatile ist unbedingt notwendig, siehe The DOTNET Memory Model.

Falls es keine konkreten Einwände gibt, dass das Singleton-Objekt auch schon etwas früher instanziiert werden darf, ist der unter Eager Creation beschriebene Code einfacher und schneller und daher in C# vorzuziehen.

Implementierung in Visual Basic .NET

Die folgende Implementierung ist threadsicher.

  Public Class Singleton
 
    ' Variable zur Speicherung der einzigen Instanz.
    Private Shared instance As Singleton = Nothing
 
    ' Hilfsvariable für eine sichere Threadsynchronisierung.
    Private Shared ReadOnly mylock As New Object()
 
    ' Konstruktor ist privat, damit die Klasse nur aus sich selbst heraus instanziiert werden kann.
    Private Sub New()
        '
    End Sub
 
    ' Diese Shared Methode liefert die einzige Instanz der Klasse zurück.
    Public Shared Function GetInstance() As Singleton
        SyncLock (mylock)
            If instance Is Nothing Then
                instance = New Singleton
            End If
        End SyncLock
 
        Return instance
 
    End Function
 
  End Class
 
  ' Zugriff über Dim s As Singleton = Singleton.GetInstance()

Implementierung in C++

Vorsicht: Die beiden folgenden Implementierungen sind nicht korrekt, da mehr als nur eine Instanz erstellt werden kann, sofern mehrere Threads gleichzeitig getInstance() aufrufen. Sie dienen nur als Beispiel und sollten in dieser Form ohne Locking nicht in großen Projekten verwendet werden.

Erste Methode: hat den Vorteil, dass bei Programmende das Objekt automatisch zerstört wird (und der Destruktor aufgerufen wird). Darüber, wann das genau passiert, hat man aber keine Kontrolle.

   class cSingleton 
   { 
   private: 
      cSingleton() {}   // von außen keine Instanzen erzeugbar 
      cSingleton(const cSingleton&) {}             // nicht kopierbar
      cSingleton& operator=(const cSingleton&) {}  // nicht zuweisbar
      ~cSingleton() {}
   public: 
      static cSingleton& getInstance(); 
   }; 
 
   cSingleton& cSingleton::getInstance() 
   { 
      static cSingleton instance; 
      return instance; 
   }

Zweite Methode: Vorteil dieser ist, dass man bei Erzeugung des Objektes ein spezialisiertes Objekt erzeugen kann, man hat also Polymorphie. Außerdem hat man durch Hinzufügen einer statischen Destroy()-Funktion volle Kontrolle darüber, wann das Singleton wieder zerstört wird.

   class Singleton
   {
   private:
      static Singleton* instance;
      Singleton() {}
      Singleton(const Singleton&) {}
      ~Singleton() {}
   public:
      static Singleton& getInstance();
      static void destroy();
   };
 
   Singleton* Singleton::instance = 0;
 
   Singleton& Singleton::getInstance()
   {
      if ( !instance )
         instance = new Singleton();
      return *instance;
   }
 
   void Singleton::destroy()
   {
      if ( instance )
         delete instance;
      instance = 0;
   }

Dritte Methode: Bietet eine Basisklasse, um auf einfachste Weise eine Klasse als Singleton auszuweisen.

   template <class T_DERIVED>
   class CSingleton
   {
      public:
         static T_DERIVED& GetInstance()
         {
            static T_DERIVED oInstance ;
            return oInstance ;
         }
 
      protected:
         CSingleton(){}
 
      private:
         CSingleton( const CSingleton& ) ;
         CSingleton& operator=( const CSingleton& ) {return *this;}
   } ;
 
   // Verwendung
   class CMySingleton : public CSingleton< CMySingleton >
   {
      friend class CSingleton< CMySingleton >;
 
      private:
         CMySingleton(){}
 
      //...
   };

Implementierung in ActionScript (Version 2)

class SingletonClass
{
        private static var _instance:SingletonClass;
 
        private function SingletonClass()
        {
        }
        /**/
        public static function getInstance():SingletonClass {
                if(!_instance) _instance = new SingletonClass();
                return _instance;
        }
        /**/
        public function doSomething()
        {
        }
}
 
/*
 
@use:
import SingletonClass;
 
SingletonClass.getInstance().doSomething();
 
*/

Implementierung in ActionScript (Version 3)

In ActionScript 3 können Konstruktoren nicht als privat deklariert werden. Eine mögliche Lösung besteht darin, mittels einer privaten Klasse sicherzustellen, dass der Konstruktor nur von innerhalb der Singletonklasse aufgerufen werden kann:

package {
   public class Singleton {
 
      private static var _instance:Singleton = null;
 
      public function Singleton(se:SingletonEnforcer) {
         if(se === null) {
            throw new Error('Singleton kann nicht direkt erstellt werden. Verwende Singleton.instance');
         } 
      }
 
      public static function get instance():Singleton {
         if(_instance === null) {
            _instance = new Singleton(new SingletonEnforcer() );
         }
         return _instance;
      }
 
   }
}
 
internal class SingletonEnforcer {}

Implementierung in PHP (ab Version 5)

 <?php
 // Die Singleton-Klasse
 final class Singleton {
 
   // Anlegen der Instanz
   private static $instance = NULL;
 
   // Konstruktor private, damit die Klasse nur aus sich selbst heraus instanziiert werden kann.
   private function __construct() {}
 
   // Diese statische Methode gibt die Instanz zurueck.
   public static function getInstance() {
 
       if (NULL === self::$instance) {
           self::$instance = new self;
       }
       return self::$instance;
   }
   // Klonen per 'clone()' von außen verbieten.
   private function __clone() {}
 }
 
 // Erzeugen einer Instanz der Klasse
 $singleton = Singleton::getInstance();
 ?>

Implementierung in Python (ab Version 2.2)

  class Singleton(object):
      def __new__(type, *args):
          # Falls es noch keine Instanz dieser Klasse gibt, wird eine erstellt und in _the_instance abgelegt.
          # Diese wird dann jedesmal zurückgegeben.
          if not '_the_instance' in type.__dict__:
              type._the_instance = object.__new__(type)
          return type._the_instance
 
      def __init__(self):
          if not '_ready' in dir(self):
              # Der Konstruktor wird bei jeder Instanziierung aufgerufen.
              # Einmalige Dinge wie zum Beispiel die Initialisierung von Klassenvariablen müssen also in diesen Block.
              self._ready = True

Implementierung in Perl

Die Methode instance gibt $instance zurück, bzw. initialisiert es vorher noch, wenn dies noch nicht geschehen ist.

package My::Singleton;
 
use strict; use warnings;
 
my $instance;
 
sub instance() {
        return $instance or $instance = bless {};
}

Dies kann dann mit dem folgenden Code genutzt werden:

use My::Singleton;
 
my $eins = My::Singleton->instance;   # eine neue Instanz
my $zwei = My::Singleton->instance;   # die gleiche Instanz

Mit CPAN-Modul

Etwas erweiterte Funktionalität bietet das CPAN-Modul Class::Singleton.

Eager Creation

Zwar ist auch das oben in Java gezeigte Beispiel sicher bezüglich Nebenläufigkeit, weil die zentrale Methode getInstance mit dem Schlüsselwort synchronized markiert ist. Eine einfachere Alternative dazu stellt jedoch die Möglichkeit dar, das Einzelstück bereits während der Initialisierung der Klasse zu erzeugen, die Zugriffsmethode muss es dann nur noch zurückgeben. Daher muss sie nicht synchronisiert werden, was den Zugriff etwas beschleunigt. Dieses Verfahren ist auch als eager creation (deutsch „begierige Erzeugung“) bekannt.

Implementierung in Java

In Java ist diese Implementierung dem Lazy Creation Ansatz vorzuziehen. Die Initialisierung findet durch das späte Initialisieren der Klasse erst statt, wenn die Klasse Singleton referenziert wird.^[5] Da der Zugriff nur via getInstance() erfolgt, ist dies auch der spätest mögliche Zeitpunkt und entspricht somit der Lazy Evaluation ohne den Synchronisierungs-Overhead.

  public final class Singleton {
 
      /** Privates Klassenattribut, einzige Instanz der Klasse wird erzeugt. */
      private static final Singleton INSTANCE = new Singleton();
 
      /** Konstruktor ist privat, darf nicht von außen instanziiert werden. */
      private Singleton() {}
 
      /** Statische Methode „getInstance()“ liefert die einzige Instanz der Klasse zurück. */
      public static Singleton getInstance() {
          return INSTANCE;
      }
      // Hier folgen die Variablen des Singletons (nicht static!)   
 
      // Nun kommen die public Methoden, über die auf das Singleton zugegriffen wird
 
      // und schlussendlich noch die (private) Methoden, die die Implementierung enthalten. 
 
      // Wichtig: Methoden, die auf instanz-Variablen zugreifen müssen mit entsprechenden Mitteln
      // synchronisiert werden, da es das Singleton nur 1x gibt und somit die Variablen automatisch global sind
      // und von mehreren Threads gleichzeitig darauf zugegriffen werden kann.
 
 }

Eine Alternative, welche die Instanz erst beim ersten Aufruf von getInstance() erzeugt, ist unter dem Namen initialization on demand holder idiom bekannt. Dabei wird die Instanz in einer inneren Klasse Holder erzeugt, welche erst beim ersten Aufruf von getInstance() geladen wird, und nicht schon beim Laden der Klasse Singleton:

  public final class Singleton {
 
      /** Private Klasse, einzige Instanz von Singleton wird beim Laden von Holder erzeugt. */
      private static class Holder {
          private static final Singleton INSTANCE = new Singleton();
      }
 
      /** Konstruktor ist privat, darf nicht von außen instanziiert werden. */
      private Singleton() {}
 
      /** Statische Methode „getInstance()“ liefert die einzige Instanz der Klasse zurück. */
      public static Singleton getInstance() {
          return Holder.INSTANCE;
      }
 
 }

Hierdurch können andere statische Methoden von Singleton gerufen oder in dieser definierte Konstanten referenziert werden, ohne INSTANCE bereits zu erzeugen.

Alternative Implementierung mit Enum in Java ab Version 5

Ab Version 5 kann zur Implementierung des Singleton-Patterns das Sprachkonstrukt Enum genutzt werden, welches außerdem direkt die Serialisierbarkeit ermöglicht^[6].

  public enum Singleton {
      INSTANCE;
      public void doSomething(){
            //TODO
      }
  }

Zugriff über Singleton.INSTANCE.doSomething()

Implementierung in C#

Eine threadsichere Methode, entnommen aus dem MSDN-Mag^[7].

  using System ;
 
  class Singleton
  {
    private Singleton() {  /* ...hier optional Initialisierungscode... */ }
    public static readonly Singleton Instance = new Singleton() ;
  }
 
  // Zugriff über
  Singleton s = Singleton.Instance ;

Das Singleton-Prinzip wird bei C# durch zwei Maßnahmen erreicht:

1. Durch die Deklaration des Konstruktors als privat (private Singleton(){}) kann dieser von außerhalb der Klasse nicht mehr aufgerufen werden – das Erstellen des Objektes ist also nur noch von innerhalb der Klasse möglich.
2. Das statische öffentliche Feld Instance speichert und liefert schreibgeschützt Zugriff auf das einzige Objekt der Klasse.

Wichtig: Der Konstruktor wird von der CLR nicht automatisch beim Programmstart aufgerufen. Erst beim ersten Zugriff auf eine Klasse werden alle statischen Member der Klasse initialisiert – in diesem Fall die Instanziierung des einen Objektes. Wenn also nie auf diese Klasse zugegriffen wird, wird der Konstruktor auch niemals ausgeführt – und das Objekt wird nie erstellt. Dieser Effekt tritt auch dann noch ein, wenn die Klasse selbst als statisch deklariert wird.

Möchte man sichergehen, dass das Singleton-Objekt beim Programmstart erstellt wird, so muss man einen beliebigen Zugriff in das Hauptprogramm („public static void Main() { }“) einbauen.

Varianten

1. Wenn man seine Klasse wie in o. g. Beispiel nicht von einer anderen Klasse ableiten muss, kann man die Klasse auch einfach als statisch deklarieren – das entspricht immer noch dem Singleton-Prinzip. Das o. g. Beispiel ist eigentlich nur ein Workaround für die Tatsache, dass man in C# statische Klassen nicht von anderen Klassen ableiten kann.
2. Möchte man eine bestimmte Anzahl Instanzen dieser Klasse (Multiton), so kann man einfach weitere statische öffentliche Instanzfelder hinzufügen (public static readonly Singleton Instance2 = new Singleton();).

Implementierung in Perl

Hier wird $instance bereits bei der Initialisierung von Singleton angelegt. Durch das :shared wird das Beispiel außerdem thread-safe.

package Singleton;
 
use strict; use warnings;
 
my $instance :shared = bless {};
 
sub instance() { return $instance; }
 
42;

Das Borg-Pattern

Unter Python gibt es auch mehrere Ansätze für das Singleton-Entwurfsmuster, allerdings wird hier allgemein eher das Borg-Pattern angewendet:

class Borg(object):
    _shared = {}
    def __new__(cls,*args,**kwargs):
        inst = object.__new__(cls)
        inst.__dict__ = cls._shared
        return inst

Im Gegensatz zum Singleton können mehrere Instanzen erstellt werden, allerdings teilen sich alle Instanzen der Borg-Klasse ihre Attribute.

Der Name Borg stammt aus einem Posting von Alex Martelli im ASPN und bezieht sich auf Star Trek.^[8]

Verwandte Entwurfsmuster

Die Eigenschaften des Einzelstückes treffen für viele Klassen der anderen Muster zu, so dass diese dann als Einzelstücke ausgeführt werden.

Zum Beispiel sind abstrakte Fabriken, Erbauer (Entwurfsmuster) oder Prototypen oft auch Einzelstücke.

Einzelnachweise

1. ↑ Singleton Considered Stupid
2. ↑ Singletons are Pathological Liars
3. ↑ Injecting Reflection to test the Singleton
4. ↑ http://www.ibm.com/developerworks/java/library/j-dcl.html
5. ↑ Tim Lindholm, Frank Yellin: The JavaTM TMVirtual Machine Specification. 2. Auflage. S. Abschnitt 2.17.4 (online, abgerufen am 22. Januar 2007).
6. ↑ Joshua Bloch: Effective Java Second Edition. Item 3: Enforce the singleton property with a private constructor or an enum type
7. ↑ http://msdn.microsoft.com/de-de/magazine/cc188779.aspx
8. ↑ Alex Martelli: Singleton? We don’t need no stinkin’ singleton: the Borg design pattern. Posting im „ActiveState Programmer Network“ vom 27. August 2001 [22. Januar 2006]

Weblinks

 Wikibooks: Muster: Singleton – Lern- und Lehrmaterialien

• Singleton (englisch)
• Beispiel für die Implementierung des Singleton-Patterns in Java

• Exploring the Singleton Design Pattern (englisch)
• Double Checked Locking is broken in Java (englisch)
• Javascript implementation of a Singleton Pattern (englisch)
• Beispiel für ein Singleton unter PHP5
• An Overview of the Java Memory Model (JMM)

Entwurfsmuster der Viererbande

Erzeugungsmuster:  Abstrakte Fabrik | Singleton | Builder | Fabrikmethode | Prototyp

Strukturmuster:  Adapter | Brücke | Decorator | Fassade | Flyweight | Kompositum | Stellvertreter

Verhaltensmuster:  Observer | Visitor | Interpreter | Iterator | Kommando | Memento | Schablonenmethode | Strategie | Vermittler | Zustand | Zuständigkeitskette

(Klassenmuster sind kursiv dargestellt)