Klassifikation von Mustern in der Softwareentwicklung
(Bild: Kenneth Summers / shutterstock.com)
Muster lassen sich ebenso klassifizieren wie Entwurfsmuster, und das Buch "Pattern-Oriented Software Architecture" bietet eine gute Grundlage.
In meinem letzten Artikel habe ich die Klassifizierung von Entwurfsmustern vorgestellt, die auf dem wegweisenden Buch "Design Patterns: Elements of Reusable Object-Oriented Software [1]" basieren. Heute stelle ich eine allgemeinere Klassifizierung von Mustern vor, die auf dem zweiten wegweisenden Buch "Pattern-Oriented Software Architecture, Volume 1 [2]" beruhen.
Die Klassifizierung in meinem letzten Artikel "Klassifizierung von Design Patterns in der Softwareentwicklung [3]" bezog sich auf Entwurfsmuster, aber in diesem Artikel "Klassifizierung von Mustern" geht es um Muster. Das ist Absicht, denn die Klassifizierung von "Pattern-Oriented Software Architecture, Volume 1 [4]" (kurz POSA 1) ist allgemeiner als die von "Design Patterns: Elements of Reusable Object-Oriented Software [5]". Um es kurz zu machen, enthält die heutige Klassifizierung die letzte.
Pattern-Oriented Software Architecture, Volume 1
Hier ist das große Bild der Muster, die in POSA 1 vorgestellt werden.
POSA 1 verwendet zwei Arten der Klassifizierung. Es klassifiziert die Muster nach ihrer strukturellen Kategorie und nach ihrer Problemkategorie. Bevor ich auf die beiden Klassifizierungen eingehe, möchte ich ein paar Worte zu den fettgedruckten Mustern in der Tabelle schreiben, auf die ich allesamt eingehen werde.
Die Entwurfsmuster Proxy, Publish-Subscriber und Counted Pointer sind besonders. Proxy ist bereits Bestandteil des Buches "Design Patterns: Elements of Reusable Object-Oriented Software [6]" und Publish-Subscriber ist dem Observer-Muster sehr ähnlich, das ebenfalls in dem bereits erwähnten Buch enthalten ist. Außerdem sollte man das Counter Pointer Idiom kennen und verwenden. In C++11 nennen wir es std::shared_ptr [7].
Strukturelle Kategorien
Die strukturelle Kategorisierung ist eine Kategorisierung nach ihrem Umfang und ihrer Abstraktion:
- Architekturmuster beschreiben die grundlegende Struktur des gesamten Softwaresystems. Sie basieren oft auf Entwurfsmustern.
- Entwurfsmuster definieren das Zusammenspiel der Komponenten und haben ihren Schwerpunkt auf Subsystemen.
- Ein Idiom ist eine Implementierung einer Architektur oder eines Entwurfsmusters in einer konkreten Programmiersprache. Das beliebte Idiom in C++ ist Resource Acquisition Is Initialization (RAII). Container, Smart Pointer und Locks setzen dies um.
Ich möchte meine Gedanken über Architekturmuster, Entwurfsmuster und Idiome gerne nochmals auf den Punkt bringen:
- Die Strukturkategorien gehen von abstrakt bis konkret. Idiome sind die konkretesten.
- Sie wirken auf der Makroebene (Architekturmuster), der Mikroebene (Designmuster) und der Programmiersprache (Idiome).
- Architekturmuster haben das System, Entwurfsmuster die Subsysteme und Idiome die Programmiersprache im Blick.
Schauen wir uns die verschiedenen Problemkategorien an.
Problemkategorien
In "Pattern-Oriented Software Architecture, Volume 1 [8]" gibt es zehn verschiedene Problemkategorien. Ich werde sie und ihre Muster in kompakter Form vorstellen, bevor ich in den nächsten Artikeln in einige von ihnen tiefer eintauche.
- From Mud to Structure bietet eine kontrollierte Zerlegung einer Gesamtsystemaufgabe in kooperierende Teilsysteme an.
- Layers: Zerlege eine Aufgabe in Schichten. Jede Schicht hat eine bestimmte Verantwortung und erbringt einen Dienst für eine höhere Schicht.
- Pipes and Filters: Decompose a task that performs complex processing into a series of separate elements that can be reused. This can improve performance, scalability, and reusability by allowing task elements that perform the processing to be deployed and scaled independently (https://docs.microsoft.com/en-us/azure/architecture/patterns/pipes-and-filters)
- Blackboard: Mehrere spezialisierte Subsysteme fügen ihr Wissen zusammen, um eine mögliche Teillösung zu erstellen. Sie wird für Probleme verwendet, für die keine deterministische Lösung bekannt ist.
- Distributed Systems baut Systeme, deren Komponenten sich in verschiedenen Prozessen oder Adressräumen befinden.
- Broker: Strukturiert verteilte Softwaresysteme, die mit entfernten Dienstaufrufen interagieren. Er ist für die Koordination der Kommunikation, ihrer Ergebnisse und Ausnahmen zuständig.
- Interactive Systems baut ein System mit einer Mensch-Computer-Interaktion.
- Model-View-Controller (MVC): Unterteilt die Programmlogik einer Benutzeroberfläche in die einzelnen Komponenten Model, View und Controller. Das Model verwaltet die Daten und Regeln der Anwendung. Die View stellt die Daten dar, und der Controller interagiert mit dem Benutzer.
- Presentation-Abstraction-Controller (PAC): ist dem MVC ähnlich. Im Gegensatz zum MVC hat das PAC eine hierarchische Struktur von Agenten, wobei jeder Agent aus einem Präsentations-, Abstraktions- und Kontrollteil besteht.
- Adaptable Systems macht eine Anwendung erweiterbar und anpassbar an neue Anforderungen.
- Mikrokernel: Trennt einen minimalen Funktionskern von der erweiterten Funktionalität.
- Reflection: Teilt ein System in zwei Teile: eine Metaebene und eine Basisebene. Die Metaebene unterstützt die Systemeigenschaften und macht es selbstreflexiv. Die Basisebene umfasst die Anwendungslogik.
- Structural Decomposition zerlegt eines Systems in Subsysteme und komplexe Komponenten, in geeignet kooperierende Komponenten.
- Whole-Part: Baut eine Aggregation von Komponenten, um aus den Teilen ein Ganzes zu machen. Bietet eine gemeinsame Schnittstelle für die Teile an. Dieses Entwurfsmuster ist dem Composite-Pattern [9] aus dem Buch "Design Patterns: Elements of Reusable Object-Oriented Software [10]".
Organization of Work
arbeitet mit mehreren Komponenten zusammen, um einen komplexen Dienst anzubieten.
- Master-Slave: Der Master verteilt seine Arbeit an seine Slaves und sammelt die Ergebnisse von ihnen ein.
- Access Control schützt und kontrolliert den Zugang zu Diensten und Komponenten:
- Proxy: Es handelt sich um einen Wrapper, der vom Client aufgerufen wird, um auf das eigentliche Objekt zuzugreifen. Ein Proxy fügt normalerweise zusätzliche Logik wie Caching, Sicherheit oder Verschlüsselung hinzu. Diese zusätzliche Logik wird vor dem Client verborgen.
- Management verwaltet eine homogene Menge von Objekten, Diensten und Komponenten in ihrer Gesamtheit.
- Command Processor: Verwandelt Befehle in Objekte, sodass ihre Ausführung geplant, gespeichert oder später rückgängig gemacht werden kann.
- View Handler: ...helps to manage all views that a software system provides. A view handler component allows clients to open, manipulate and dispose of views. It also coordinates dependencies between views and organizes their update. ([ [11]Pattern-Oriented Software Architecture, Volume 1 [12])
- Communication Organisiert die Kommunikation zwischen den Komponenten.
- Forwarder-Receiver: Provides transparent interprocess communication for software systems with a peer-to-peer interaction model. It introduces forwarders and receivers to decouple peers from the underlying communication mechanisms. (Pattern-Oriented Software Architecture, Volume 1 [13])
- Client-Dispatcher-Server: Führt den Dispatcher als Schicht zwischen Clients und Servern ein. Der Dispatcher sorgt für Transparenz zwischen den Clients und den Servern.
- Publish-Subscriber: Ermöglicht es dem Publisher, alle Subscriber automatisch zu benachrichtigen. Dieses Entwurfsmuster ist dem Observer [14] Desgn Pattern aus dem Buch "Design Patterns: Elements of Reusable Object-Oriented Software [15]".
Resource Managment
hilft bei der Verwaltung gemeinsam genutzter Komponenten und Objekte.
- Counted Pointer: Führt einen Referenzzähler für dynamisch zugewiesene gemeinsame Objekte ein. std::shared_ptr [16] ist das prominente Beispiel in C++.
Wie geht's weiter?
Mit diesem Artikel beende ich meine Einführung in Patterns. In meinem nächsten Artikel stelle ich die Struktur eines Design Patterns auf der Grundlage des Buches "Design Patterns: Elements of Reusable Object-Oriented Software [17]" vor. (rme [18])
URL dieses Artikels:
https://www.heise.de/-7203402
Links in diesem Artikel:
[1] https://en.wikipedia.org/wiki/Design_Patterns
[2] https://en.wikipedia.org/wiki/Pattern-Oriented_Software_Architecture
[3] https://www.heise.de/blog/Klassifizierung-von-Design-Patterns-in-der-Softwareentwicklung-7194039.html
[4] https://en.wikipedia.org/wiki/Pattern-Oriented_Software_Architecture
[5] https://en.wikipedia.org/wiki/Design_Patterns
[6] https://en.wikipedia.org/wiki/Design_Patterns
[7] https://en.cppreference.com/w/cpp/memory/shared_ptr
[8] https://en.wikipedia.org/wiki/Pattern-Oriented_Software_Architecture
[9] https://en.wikipedia.org/wiki/Composite_pattern
[10] https://en.wikipedia.org/wiki/Design_Patterns
[11] https://en.wikipedia.org/wiki/Pattern-Oriented_Software_Architecture
[12] https://en.wikipedia.org/wiki/Pattern-Oriented_Software_Architecture
[13] https://en.wikipedia.org/wiki/Pattern-Oriented_Software_Architecture
[14] https://refactoring.guru/design-patterns/observer
[15] https://en.wikipedia.org/wiki/Design_Patterns
[16] https://en.cppreference.com/w/cpp/memory/shared_ptr
[17] https://en.wikipedia.org/wiki/Design_Patterns
[18] mailto:rme@ix.de
Copyright © 2022 Heise Medien