Muster in der Softwaretechnik

Johannes Biermann, Florian Gaul, Christian Hoffmann

Informationstechnik BA Horb

Florianstraße 15 72160 Horb

i05001@ba-horb.de i05004@ba-horb.de i05008@ba-horb.de

Abstract: Nowadays reusable software is a common design goal in software development. Many methods exist to ensure high software quality.

The object-oriented approach is one of them and is widely used. You can programme classes that abstract the problem from a certain topic and these classes can be reused in another software project. But this paradigm does not necessarily ensure software quality. The main goal is to reuse your development ideas and decisions. A class does not include the ideas from the design decisions. This is the reason why software patterns exist. They provide an abstract collection of different problems and solutions to them.

The idea of creating a pattern catalogue goes back to the architect Christopher Alexander. He made an abstract collection for common architectural problems. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, also known as the Gang of Four (GoF), adopted the ideas into the software world and published the book “Design Patterns: Elements of Reusable Object-Oriented Software“.

There are two different categories of patterns in Software-Development: architecture patterns and design patterns. The architecture pattern describes the whole system. A typical example of an architecture pattern is the 3-tier architecture. A design pattern describes more specific problems in software development, for example observing a state in a spreadsheet cell.

The first part of this study defines the expression “pattern”. An overview over architecture patterns and design pattern is then given, followed by a more detailed description and some examples. The next part discusses antipatterns, which look like patterns but define the way you should not design your software and solutions are given. The last part covers some special topics like idioms and languages that have built-in patterns. To give a practical example another chapter shows software that can automatically generate code for patterns.

Inhaltsverzeichnis

1. Einleitung........................................................................................................................................ 3 2. Definition ........................................................................................................................................ 6 3. Kategorisierung Muster.................................................................................................................. 6

3.1. Architekturmuster ....................................................................................................6

3.2. Objektorientierte Muster .........................................................................................6

3.3. Analyse-Muster........................................................................................................7

3.4. Entwurfsmuster ........................................................................................................7

3.5. Idiome.......................................................................................................................7

4. Beschreibungsmittel von Mustern................................................................................................. 7 4.1. UML-Diagramme zur Beschreibung von Mustern................................................7

4.2. Textuelle Beschreibung von Mustern.....................................................................8

5. Einsatz von Mustern in der Praxis................................................................................................. 8 6. Überblick Entwurfsmuster............................................................................................................. 9

6.1. Adapter .....................................................................................................................9

6.2. Fassade (Facade)....................................................................................................11

6.3. Kommando (Command)........................................................................................12

6.4. Abstrakte Fabrik (Abstract Factory).....................................................................13

7. Überblick Architekturmuster ....................................................................................................... 14 7.1. Schichtenarchitektur (Layer).................................................................................15

7.2. Broker .....................................................................................................................15

7.3. Blackboard .............................................................................................................15

7.4. Pipes and Filter ......................................................................................................15

7.5. Model View Controller MVC...............................................................................16

7.6. Presentation Abstraction Control PAC (Darstellungs-Abstraktions-Kontrolle)16

7.7. Microkernel ............................................................................................................16

7.8. Reflexion ................................................................................................................16

7.9. Architekturmuster Beispiel Microkernel..............................................................17

7.9.1. Struktur............................................................................................................17

7.9.2. Vor- und Nachteile von Microkerneln ..........................................................22

7.9.3. Bekannte Software, die Microkernel einsetzt...............................................23

8. Patterns und Einsatz in funktionale oder imperativen Sprachen ............................................... 23 9. Antipatterns (Antimuster) ............................................................................................................ 24

9.1. Design-Antipatterns...............................................................................................24

9.1.1. Gott-Objekt .....................................................................................................24

9.1.2. Goldener Hammer ..........................................................................................24

9.2. Programmierungs-Antipatterns.............................................................................25

9.2.1. Zwiebel............................................................................................................25

9.2.2. Lavafluss .........................................................................................................25

9.3. Sonstiges.................................................................................................................25

10. Programmiersprachen mit eingebauten Mustern...................................................................... 25 11. Softwareunterstützung am Beispiel von StarUML .................................................................. 26

11.1. Einbinden von neuen Patterns in das bestehende Modell .................................27

11.2. Übernehmen von Patterns in bestehende Modell ..............................................28

11.3. Code-Erzeugung ..................................................................................................29

12. Fazit............................................................................................................................................. 30

1. Einleitung

Ein Stück Programmcode oder auch eine Klasse ist nur eine kleine Einheit eines Programms. Durch Bündeln dieser Elemente zu einer Bibliothek oder Framework kann man eine Sammlung von wieder verwendbarem Code erzeugen. Wenn der Code oder das Framework gut dokumentiert wurde, so kann man diesen Teil in einer Vielzahl von Anwendungen erneut verwenden.

Doch der Programmcode ist nur ein Teil der Anwendung. Während der Anwendungsentwicklung entstehen neben Programmcode weitere Artefakte eines Programms. Diese Artefakte sind Anwendungsspezifikation, Anwendungsentwurf und Anwendungsdesign. Es stellt sich daher die Frage, wie man dieses Wissen in der Softwareentwicklung wieder verwenden kann?

In anderen Disziplinen haben sich so genannte Musterkataloge bereits etabliert. Man entwickelt hier auch nicht alles komplett neu, sondern nutzt bewährte Ansätze. Solche Kataloge lassen sich im Maschinenbau, der BWL und in der Architektur finden. Die erste Beschreibung eines „Patterns, also Musters, führte der Architekt Christopher Alexander 1974 ein. Er beschrieb verschiedene Architekturprobleme in seinem Buch „A Pattern Language“ und stellte einen Lösungsansatz für wiederkehrende Probleme dar. In dem folgenden Beispiel sieht man, wie man Türen in einem Raum positioniert.

Türen in den Ecken (entnommen aus [Sk00])

Musternummer 196

Design Problem

Ob ein Raum funktioniert oder nicht (wörtl: erfolgreich ist), hängt im Wesentlichen von der Lage der Türen ab. Wenn die Türen Unruhe erzeugen und dadurch die Stellen des Raums entwerten, wird dieser Raum niemals gemütlich werden.

Erklärung d. Problems

In Räumen mit nur einer Tür sollte diese im Allgemeinen in der Ecke liegen. Mittige Türen schaffen meist eine Störungszone, die den Raum in für sinnvolle Nutzungen zu kleine Teilräume zersplittert. Nur bei langen, schmalen Räumen kann eine Mitteltür sinnvoll sein, zumal wenn sie den Raum in zwei nutzbare Raumhälften aufteilt, die jeweils unterschiedliche Funktionen aufnehmen.

1

Auch bei Räumen mit mehreren Türen ist die Ecklage sinnvoll, wobei hier auch noch die Beziehungen zwischen den einzelnen Türen eine Rolle spielt. Die Türen sollten also wenn möglich an einer Seite liegen, so dass der Raum nicht von einer Verkehrsfläche durchschnitten wird.

Schließlich sollte man noch beachten, dass dieses Muster nicht auf sehr große Räume zutrifft. In einem sehr großen Raum oder in einem Raum mit einem großen Tisch in der Mitte können die Türen in der Mitte sein und trotzdem einen formellen und großzügigen Eindruck vermitteln. Tatsächlich ist es in diesem Fall vielleicht sogar besser, wenn sie in der Mitte sind, damit diese Wirkung entsteht. Das funktioniert aber nur, wenn der Raum groß genug ist.

Lösung Außer in sehr großen Räumen sind Türen in der Mitte der Wand selten sinnvoll. Doch wäre eine solche Anordnung z.B. bei einem Eingangsraum, dessen Charakter ja gerade von der Tür bestimmt wird, sinnvoll. In den meisten Räumen jedoch, vor allem in den kleinen, empfiehlt es sich, die Tür soweit wie möglich in die Ecke zu schieben. In Durchgangsräumen sollten beide Türen an einer Seite des Raumes liegen.

2

Erklärung d. Lösung

Übergeordnete Muster

Von Raum zu Raum (131)

Mehrere Sitzplätze (142)

Wechsel von Hell und Dunkel (135)

Untergeordnete Muster

Ornament (249)

Niedrige Tür (224)

Schränke zwischen Räumen (198)

Gerahmte Öffnungen (225)

Solide Türen mit Glas (237)

Tabelle 1: Beispiel Architekturmuster

Die Beschreibung des Problems abstrahiert von anwendungsspezifischen Details und verallgemeinert das Muster. Dieses Beispiel kann nun bei allen Architekturproblemen, wo Türen benötigt werden zu Rate gezogen werden. Werden solche Muster geschickt kategorisiert und eingeordnet, so hat der Anwender die Möglichkeit während des Entwurfs schnell nach einer Problemlösung zu suchen und muss sich nicht erst lange Gedanken machen.

Inspiriert durch den Ansatz von Christopher Alexander versuchten Erich Gamma, Richard Helm, Ralph Johnson und John Vlissides, auch als Gang of Four (GoF) bekannt, diese Ideen auf die Softwaretechnik zu übertragen. Heraus kam dabei das 1994 veröffentlichten das Buch "Design Patterns - Elements of Reusable Object-Oriented Software". Es Dieses Werk wurde in der darauf folgenden Zeit zum ist das Standardwerk für Muster.

3

Muster sind also nicht die Problemlöser schlechthin, sondern eine Ansammlung von praktischen Lösungsmöglichkeiten, die gut funktionieren. Während der Softwareentwicklung tauchen häufige gleichartige Probleme auf, die Programmiersprachen unabhängig sind. Da bekannte Muster bereits oft angewendet wurden, kann man sicher sein, dass dieser Ansatz funktioniert und praxistauglich ist. Gerade bei komplexen Problemen kann durch den erprobten Ansatz die Qualität der Software erhöht werden.

Am Anfang wurde bereits gesagt, dass es Muster in vielen Fachbereichen gibt. Im Softwarebereich gibt es außer den Softwaremustern noch weitere Musterarten. So finden sich Muster auch bei der Gestaltung von Benutzeroberflächen und seit kurzem gibt es Designmuster für Webseiten. Diese Ausarbeitung beschäftigt sich jedoch mit Mustern, die für die Softwareentwicklung zum Einsatz kommen.

2. Definition

Software Patterns sind: „Allgemein bewährte Lösungen für Standardprobleme, also Problem/Lösungs-Paare, die in ähnlicher Form immer wieder angewendet werden können.“ (Vgl. [Sc96]).

3. Kategorisierung Muster

Grundsätzlich werden Muster zwei Kategorien zugeordnet: Architekturmuster und objektorientierte Muster.

3.1. Architekturmuster

Architektur Muster beschreiben den zugrunde liegenden strukturellen Aufbau eines Softwaresystems. Sie bilden vordefinierte Subsysteme, spezifizieren deren Verantwortlichkeiten und beinhalten Regeln und Richtlinien um die Beziehungen zwischen den Subsystemen zu organisieren.

3.2. Objektorientierte Muster

Objektorientierte Muster können weiter unterteilt werden. Dabei gilt es, die grundsätzliche Unterscheidung zwischen Analyse- und Entwurfsmuster zu treffen. Diese sind den jeweiligen Phasen des Software-Engineerings zugeordnet.

4

3.3. Analyse-Muster

Analyse-Muster dienen dazu, einen schnelleren Einstieg während der Analysephase zu gewährleisten. Sie beinhalten Klassen und Beziehungsarten, die häufig vorkommen.

3.4. Entwurfsmuster

Zu den Entwurfsmustern zählen auch die klassischen durch Gang of Four (GoF) beschriebenen Patterns. Dabei werden diese als Basis für alle anderen Patterns betrachtet. Sie sind in drei Gruppen unterteilt: Erzeugungsmuster (Creational), Strukturmuster (Structural) und Verhaltensmuster (Behavioral).

3.5. Idiome

Idiome (engl.: Dialekt, Ausdrucksweise, Spracheigentümlichkeit) beziehen sich auf eine bestimmte Sprache (z.B. Java Idioms). Sie befassen sich damit wie konkrete Probleme in der jeweiligen Sprache am besten zu lösen sind. Unter [JioA] wird ein Überblick über bekannte Java Idiome gegeben.

„Ein Idiom ist ein programmiersprachenspezifisches Muster und damit ein Muster auf einer niedrigen Abstraktionsebene. Ein Idiom beschreibt, wie man bestimmte Aspekte von Komponenten oder Beziehungen zwischen ihnen mit den Mitteln einer bestimmten Programmiersprache implementiert.“ (Vgl. [Bu96])

4. Beschreibungsmittel von Mustern

Um Muster auf eine einheitliche Art beschreiben zu können, hat sich ein mehr oder weniger ein einheitliches Notationssystem herauskristallisiert. Dabei muss auf die Beschreibung des statischen sowie des dynamischen Aspekts des Musters Wert gelegt werden. Diese werden mithilfe von UML-Diagrammen visualisiert.

4.1. UML-Diagramme zur Beschreibung von Mustern

Um die Struktur und den Ablauf von Mustern klarer zu machen, werden UML-Diagramme eingesetzt. Dabei muss unterschieden werden, welcher Teil des Musters beschrieben werden soll: Ist der Ablauf eines einzelnen Durchlaufs entscheidend zum Verständnis des Musters sollte auf die dynamische UML-Elemente zurückgegriffen werden (i.d.R.: Sequenzdiagramme, Kommunikationsdiagramme). Spielt aber der strukturelle Aufbau des Musters sowie die komplexen Beziehungen zwischen den einzelnen Klassen die tragende Rolle, sind statische Diagramme angebracht (v.a. Klassendiagramme).

5

4.2. Textuelle Beschreibung von Mustern

Um die UML-Diagramme aussagekräftiger zu machen, bedarf es noch einer textuellen Beschreibung des Ablaufs und des Aufbaus des Musters. Dazu werden mindestens folgende Bestandteile benötigt:

• Name • Problem / Context • Solution • Consequences

Um eine möglichst einheitliche Beschreibungsform von Mustern gewährleisten zu können, wurde die oben dargestellte Form von der GoF als das GoF-Schema spezifiziert. Oft reichen allerdings diese Kriterien nicht oder nur unzureichend aus um komplexe Muster verständlich zu machen. Dann kann es sinnvoll sein, weitere Aspekte in die Beschreibung mit aufzunehmen. Folgende weitere Kriterien können dazu hilfreich sein:

• Zweck • Also Known As, falls das Muster auch unter anderen Namen geläufig ist • Ein Beispielszenario, um die Problemstellung zu verdeutlichen • Vorteile und Nachteile des Musters • Beispielcode • Verwendungsbeispiele • Varianten und Strategien des Musters • Verweise auf ähnliche Muster oder alternative Lösungsansätze

5. Einsatz von Mustern in der Praxis

Da Muster allgemein gelten sollen, sind sie immer abstrakt gehalten. In den Beschreibungen finden sich teilweise benötigte Klassen und das statische und dynamische Verhalten. Um nun ein Muster in einem konkreten Anwendungsfall einsetzen zu können, muss das Muster immer auf das Problem zugeschnitten werden. Die konkrete Implementierung hängt auch von der gewählten Programmiersprache ab.

Ein Muster hat immer Stärken bei bestimmten Anforderungen, bringt jedoch auch immer gewisse Nachteile mit sich. Die Entscheidung muss daher sorgfältig geprüft werden. Daher finden sich bei einem Muster immer Verweise auf ähnliche Muster.

Zusätzlich sollten andere, nicht funktionale Aspekte wie Widerverwendbarkeit des Codes, Dokumentation und Testbarkeit der Software nicht außer Acht gelassen werden.

6

6. Überblick Entwurfsmuster

6.1. Adapter

Der Adapter ist eines der am häufigsten angewendeten Entwurfsmuster. Es gehört zur Kategorie der Strukturmuster.

Annahme: Eine Java-Bibliothek soll in ein eigenes Projekt integriert werden, besitzt aber nicht die passenden Schnittstellen. Nun müssten im eigenen Projekt alle Klassen, welche die Bibliothek nutzen wollen, eventuell erheblich umgeschrieben werden. Um die Anpassung der eigenen Klassen zur vermeiden, nutzen wir das Adapter-Muster. Damit werden die Schnittstellen der Bibliothek an das eigene Projekt adaptiert.

Abbildung 1 - Klassenadapter (UML-Diagramm)1

Das klassische Beispiel2 für den Einsatz dieses Musters sind eine runderPflock- und eine quadratischerPflock-Klasse.

Dies wäre die „QuadratischerPflock“-Klasse:

/** * Die “QuadratischerPflock”-Klasse. * Dies ist die Zielklasse. */ public class QuadratischerPflock {

1 Bildquelle: http://de.wikipedia.org/w/index.php?title=Bild:Adapter2.png&oldid=6933347 2 http://userpages.umbc.edu/~tarr/dp/lectures/Adapter-2pp.pdf

7

public void stecken(String str) { System.out.println("QuadratischerPflock stecken (): " + str); } }

Die „RunderPflock“-Klasse sieht folgendermaßen aus:

/** * Die “RunderPflock”-Klasse. * Dies ist die zu adaptierende Klasse. */ public class RunderPflock { public void inLochStecken(String msg) { System.out.println("RunderPflock inLochStecken (): " + msg); } }

Dies ist die „PflockAdapter“-Klasse:

/** * Die “PflockAdapter”-Klasse. * Das hier ist die Adapter Klasse. * Sie adaptiert einen „RunderPflock“ zu einem „QuadratischerPflock”. * Die Schnittstelle ist die eines “QuadratischerPflock”. */ public class PflockAdapter extends QuadratischerPflock { private RunderPflock runderPflock; public PflockAdapter (RunderPflock pflock) {this.runderPflock = pflock;} public void insert(String str) { runderPflock.inLockStecken(str);} }

Die hier vorgestellte Variante ist der „Klassenadapter“, es existiert auch der „Objektadapter“ (siehe Abbildung 2 - Objektadapter (UML-Diagramm)).

8

Abbildung 2 - Objektadapter (UML-Diagramm)3

6.2. Fassade (Facade)

Das Fassade-Muster gehört zur Kategorie der Strukturmuster.

Oft sind die Schnittstellen eines Subsystems sehr umfangreich und manchmal auch unübersichtlich.

Um dies zu beheben wird eine Schnittstellen-Fassade gebaut, welche die benötigten Methoden zur Verfügung stellt, die Komplexität aber verbirgt. Außerdem kann die nutzende Klasse auch bei Änderung des Subsystems gleich bleiben – Änderungen werden an der Fassade vollzogen.

3 Bildquelle: http://de.wikipedia.org/w/index.php?title=Bild:Adapter.png&oldid=6933343

9

Abbildung 3 - Fassade (UML-Diagramm)4

6.3. Kommando (Command)

Das Kommando-Muster gehört zur Kategorie der Verhaltensmuster.

Wie auf einer Fernbedienung ein Knopf gedrückt wird, sollen bei einem Auslöser mehrere Tätigkeiten ausgeführt werden. Der Auslösende will hierbei nichts von den Abläufen innerhalb des Systems wissen.

Hierzu dient das Kommando-Muster. Es kapselt und entkoppelt eine Befehlsfolge.

4 Bildquelle: http://en.wikipedia.org/w/index.php?title=Image:FacadeDesignPattern.png&oldid=170915830

10

Abbildung 4 - Kommandomuster (UML-Diagramm)5

6.4. Abstrakte Fabrik (Abstract Factory)

Eine Abstrakte Fabrik ist ein erzeugendes Muster, welches eine Schnittstelle zur Erzeugung abstrakter Produkte einer Produktfamilie definiert.

Es wird zum Beispiel eine abstrakte Fahrzeugfabrik und ein dazugehöriges abstraktes Objekt „Fahrzeug“ erstellt, die an die konkreten Fabriken „Automobilfabrik“ und „Fahrradfabrik“ vererbt, welche wiederum die konkreten Objekte „Automobil“ und „Fahrrad“ erzeugen. Dadurch werden konkrete Klassen isoliert und der Austausch ganzer Produktfamilien vereinfacht.

5 Bildquelle: http://de.wikipedia.org/w/index.php?title=Bild:KommandoMuster_Klassen.png&oldid=7250086

11

Abbildung 5 - Abstrakte Fabrik (UML-Diagramm)6

7. Überblick Architekturmuster

Architekturmuster (AM) dienen der Beschreibung einer Softwarearchitektur an sich. Sie umfassen somit die ganze Anwendung. Die AMs sind abstrakt, damit sich damit die Strukturen einer Anwendung beschreiben lassen. Ein AM dient dazu, eine Software grob zu strukturieren als auch eine zentrale Anforderung wie bestimmte Reaktionszeit eines Systems zu erreichen oder eine leichte Anpassbarkeit der Bedienoberfläche. Ein AM beschreibt die Anwendung im Globalen. Aus diesem Grund müssen Subsysteme weiter strukturiert werden. Eine weitere Strukturierung kann mit Entwurfsmustern erfolgen.7

6 Bildquelle: http://de.wikipedia.org/w/index.php?title=Bild:AbstrakteFabrik.png&oldid=7189132 7 siehe auch [Bu98] S. 27 - 219

12

7.1. Schichtenarchitektur (Layer)

Mit der Schichtenarchitektur kann man eine Anwendung in mehrere Gruppen unterteilen. Die beliebtesten Beispiele für Schichtenarchitekturen sind das OSI Netzwerkschichtenmodell und Client-Server Prinzip, dass auf mehrere Ebenen verteilt sind und verschiedene Teilgruppen der Software auf verschiedenen Maschinen laufen. Die Schichtenarchitektur kommt immer dann in Frage, wenn eine unterschiedliche Abstraktion einer Software vorgenommen werden soll und Schichten wieder verwendet werden. Im Idealfall lässt sich eine Schicht austauschen, ohne dass andere Schichten davon betroffen sind.

7.2. Broker

Durch die Broker Architektur können verteilte Anwendungen entworfen werden. Dabei sendet der Client eine Anforderung an einen Broker. Dieser Broker sucht dann den passenden Server und sendet die Antwort wieder an den Client. Ein Anwendungsbeispiel für Broker sind Java Enterprise Edition und Webservices. Dabei stellen Anwendungen Methodenaufrufe für andere Anwendungen zur Verfügung. Mit einem Netzwerk und einem speziellen Protokoll rufen dann die Anwendungen diese Methoden über das Netzwerk auf. Ein Beispiel für eine Referenzarchitektur und Protokoll ist die Common Object Request Broker Architecture (CORBA).

7.3. Blackboard

Die Blackboard Architektur wurde entworfen für Probleme, die nicht deterministisch lösbar sind oder für die noch kein vollständiger Lösungsansatz verfügbar sind. Diese Architektur ermöglicht es, Teilprobleme verschiedenen Algorithmen zuzuführen. Typische Algorithmen, die dabei zum Einsatz kommen, sind regel- und rollenbasierend, basieren auf Fuzzy Logik, neuronale Netzwerke, genetische Algorithmen und klassische mathematische Algorithmen. Die Blackboard Architektur ist in Bereichen der Bildverarbeitung und Sprach-, Bild- und Spamerkennung häufig zu finden. Wichtig bei den Blackboard Architektur ist das Zerlegen in Teilprobleme und einfaches Austauschen der verwendeten Algorithmen.

7.4. Pipes and Filter

Die Pipes and Filter (PaF) Architektur wurde für Systeme entwickelt, die Datenströme verarbeiten. Jeder Verarbeitungsschritt wird von einem Filter durchgeführt, der nach Ende der Verarbeitung wieder den Datenstrom bereitstellt (Pipes). Die Filter kann man beliebig kombinieren. Ein Anwendungsbeispiel ist ein Compiler, der Programmcode durch verschiedene Schritte ein einen Datenstrom zerlegt. Die bekannteste PaF Architektur ist jedoch UNIX. Unter UNIX existieren viele kleinere Programme, die parametrisiert werden können. Diese Programme können auf beliebige Art kombiniert werden und Datenströme aus verschiedensten Quellen verwenden.

13

7.5. Model View Controller MVC

Das MVC Muster hat sich mittlerweile zu dem bekanntesten Architekturmuster entwickelt. Mit dem MVC Muster kann man leicht änderbare grafische Anwendungen entwickeln. Die Idee dahinter ist, dass man die Oberfläche beliebig ändern kann. Die Oberfläche ist dabei die Sicht (View), die Sicht kommuniziert mit dem Controller, der wiederum die Daten mit dem Modell abgleicht. Diese Art der Änderbarkeit ist auch bei Webanwendungen gewünscht, so dass dieses Muster dort häufig zu finden ist.

7.6. Presentation Abstraction Control PAC (Darstellungs-Abstraktions-Kontrolle)

Dieses Muster ist ähnelt dem MVC Muster. Bei PAC gibt es die Abstraktion, in der die Daten gehalten werden. Die Präsentation ist die Bedienoberfläche. Der Agent hat die Aufgabe, mit beiden Teilen zu kommunizieren. Der Unterschied zu MVC ist, dass jeder PAC Teil nur einen kleinen Teil der Anwendung bereitstellt, etwa ein Knopf oder ein Fenster. Trotzdem hat PAC die positiven Eigenschaften von MVC. PAC Komponenten können vom verschiedenen Entwickler unabhängig entwickelt werden. PAC hat Vorteile bei Software, die in verschiedenen Varianten ausgeliefert werden soll, also etwa Light Version, Pro Version. Auch können einzelne Komponenten einer Oberfläche leichter als bei MVC wieder in einem anderen System verwendet werden.

7.7. Microkernel

Microkernel kommen in Softwaresystemen in Einsatz, wo leichte Portierbarkeit oder Erweiterbarkeit gewünscht ist. Dabei werden Kernfunktionen in einen kleinen Kern untergebracht. Alle weiteren Funktionen klinken sich in den Microkernel ein. Bei einem Betriebssystemkern muss bei einer Portierung auf eine andere Prozessorarchitektur im Idealfall nur der Microkernel angepasst werden. Jedoch kommt die Microkernel Architektur nicht nur bei Betriebssystemkernen zum Einsatz, auch bei normaler Software gibt es sinnvolle Anwendungsfälle. Überall, wo eine minimale Funktionsbasis und dynamische Erweiterbarkeit (auch zur Laufzeit) erforderlich sind, kann der Einsatz eines Microkernels in Betracht gezogen werden.

7.8. Reflexion

Das Reflexionsmuster hat das Ziel, eine flexibel anzupassende Software zu schaffen. Die Software wird dabei in zwei Teile unterteilt. Der erste Teil ist die Metaebene. In der Metaebene werden Informationen über die Anwendung selbst verwaltet. Hier sind Informationen über Datentypen, Strukturen, Funktionen, Methoden und Algorithmen abgelegt. Der zweite Teil benutzt immer diese Metadaten und bildet die Anwendungslogik. Durch Ändern an den Metadaten kann das Verhalten der Anwendung geändert werden ohne die Logik zu verändern.

14

Im Anschluss an die Übersicht wird das Architekturmuster Microkernel näher beschrieben.

7.9. Architekturmuster Beispiel Microkernel

Das Architekturmuster Microkernel ist meist in Betriebssystemkernen zu finden. Jedoch kann auch andere Software von diesem Modell profitieren. So basiert zum Beispiel der JBoss Java Application Server auf diesem Pattern. Natürlich ist ein Microkernel auch in Betriebsssystem-Kerneln wie Mach, Windows NT usw. zu finden. 8

7.9.1. Struktur

Ein Microkern besteht aus fünf Komponenten: (Struktur nach [Bu98] S. 171 - 192)

• Interner Server

• Externer Server

• Adapter

• Clients

• Microkern

Der Microkern ist die Hauptkomponente der Architektur. In den Microkern werden die notwendigen Kernfunktionalitäten implementiert. Ganz wichtig ist die Implementation einer Kommunikationsmöglichkeit und Ressourcenverwaltung. Die anderen beteiligten Komponenten nutzen die Kommunikationsschnittstellen des Microkerns. Bei einem Betriebssystem würden in den Microkern elementare Fähigkeiten wie Prozess- und Speicherverwaltung und Zugriffe auf Systemressourcen wie Geräte und Dateien implementiert. Der Microkern ist daher sehr klein.

Alle über die elementarsten Funktionen hinaus gehenden Funktionen werden in die internen Server implementiert. In dem internen Server sind Grundfunktionalitäten enthalten, die über die minimalen Funktionen eines Microkerns hinausgehen. Um wieder bei dem Beispiel Betriebssystem zu bleiben, findet sich in einem internen Server Treiber für Speichercontroller und Grafikkarten wieder. Der Microkern kann diese Komponenten bei Bedarf laden. Die internen Server stehen nur dem Microkern selbst zur Verfügung.

8 vgl. [Bu98] S. 171 - 192

15

Externe Server sind Komponenten, die von außen zugänglich sind. In die externen Dienste können verschiedene Funktionalitäten wie Dateisystemtreiber, weitere nicht elementare Gerätetreiber und weitere Abstraktionen usw. implementiert werden. Die Funktionalitäten der Server sind über Schnittstellen von außen zu erreichen. Die Server kommunizieren mit den internen Diensten über Schnittstellen des Microkerns. Externe Server werden jeweils als eigenständiger Prozess gestartet.

Über Adapter werden die Funktionalitäten eines Microkerns nach außen angeboten. Der Adapter kommuniziert dann mit den externen Servern des Microkerns. Ein Client greift immer über Adapter auf den Kernel zu. Der Adapter delegiert dann die Aufrufe an die verschiedenen Server des Clients und reicht die Anfrage dem Client weiter.

Sehr wichtig ist es, dass der Microkern selbst sehr klein gehalten wird. Die Kommunikationswege zwischen Kern und den Server müssen sehr schnell und effizient sein.

Abbildung 6: Struktur eines Microkernels 9

Zusammenfassend lassen sich folgende Class-Responsibility Karten finden: (vgl.[Bu98])

Klasse

Microkern

Beteiligte

Interne Server

Verantwortung

• Atomare Funktionen

• Interprozesskommunikation

• Verwaltung von Ressourcen

9 Bildquelle: http://www.techfak.uni-bielefeld.de/~dstoesse/SeminarDesignPatterns/Microkernel_Folien.pdf

16

Klasse

Interne Server

Beteiligte

Microkern

Verantwortung

• Weitere Grundfunktionen

• Kapselung systemspezifischer Funktionen

Klasse

Externe Server

Beteiligte

Microkern

Verantwortung

• Weitere gekapselte Funktionen

• Erweiterungsmöglichkeit des Kernels

Klasse

Adapter

Beteiligte

Externe Server

Microkern

Verantwortung

• Schnittstellen nach außen

• Delegiert zwischen verschiedenen Servern

• Abstrahiert von der internen Implementierung des Kernels

• Ruft Funktionen des Kernels auf

17

Klasse

Client

Beteiligte

Adapter

Verantwortung

• Anwendung, die über die Adapter kommuniziert

Bringt man nun diese Klassenzugehörigkeiten in ein Klassendiagramm, so ergibt sich folgendes Klassendiagramm:

Abbildung 7: Klassendiagramm10

In diesem statischen Klassendiagramm sieht man den Nachrichtenfluss eines solchen Systems. Der Adapter ruft dabei die passenden externen Server auf. Der Microkernel ist die zentrale Kommunikationsschnittstelle des Systems. Daher ist darauf zu achten, dass die Kommunikation sehr schnell erfolgt. Der Kern kennt seine internen Server und lädt diese bei Bedarf, während der Microkernel von den externen Servern nichts weiß. Der Adapter ruft diese Server bei Clientanforderung auf.

10 Bildquelle: http://www.techfak.uni-bielefeld.de/~dstoesse/SeminarDesignPatterns/Microkernel_Folien.pdf

18

Betrachten wir nun den dynamischen Aspekt dieses Systems:

Abbildung 8: Verhalten bei Zugriff von außen11

Die Abbildung zeigt das Verhalten des Systems, wenn ein externer Server auf Dienste von internen Servern zugreift. Zunächst sendet der externe Server eine Anforderung an den Microkernel. Der Microkernel ruft den passenden internen Server auf und leitet den Aufruf an diesen weiter. Nun gibt der interne Server die Ergebnisse seiner Arbeit an den Microkernel weiter, der diese wiederum an den externen Server zurückgibt.

11 Bildquelle: http://www.techfak.uni-bielefeld.de/~dstoesse/SeminarDesignPatterns/Microkernel_Folien.pdf

19

Abbildung 9: Dynamische Aspekte12

In dieser Abbildung ist der ganze dynamische Ablauf zu sehen, wenn ein Client einen Dienst von dem Microkernel benötigt.

Der Client sendet einem Adapter einen Methodenaufruf. Das System muss dafür einen entfernten Prozeduraufruf (RPC) besitzen, sonst wäre der Client untrennbar mit dem Adapter verbunden. Nun bittet der Adapter den Mikrokern um den Aufbau einer Kommunikation mit dem externen Server. Nun sucht der Mikrokern die Adresse des externen Servers und teilt dem Adapater diese Adresse mit. Der Adapter kann nun direkt mit dem externen Server kommunizieren. Der externe Server empfängt nun die Nachricht des Adapters und führt den Aufruf intern durch. Die Ergebnisse werden wieder dem Adapter übermittelt, der diese wiederum an den Client zurück liefert.

7.9.2. Vor- und Nachteile von Microkerneln

• Kleiner Systemkern, der gut testbar ist

• Dynamisch durch externe Server zu erweitern

• Kapseln von systemspezifischen Bestandteilen , dadurch leicht portierbar

• Verschiedene Sichten auf das System (durch Adapter und externe Server)

• Externe Server laufen unter normalen Benutzerrechten

- Durch die vielen Kommunikationswege langsamer als ein monolithischer Kern

12 Bildquelle: http://www.techfak.uni-bielefeld.de/~dstoesse/SeminarDesignPatterns/Microkernel_Folien.pdf

20

- Synchronisation zwischen vielen Prozessen aufwendig

7.9.3. Bekannte Software, die Microkernel einsetzt

Microkernel kommen in verschieden Betriebssystemen zum Einsatz. Man findet jedoch oft hybride Kernelformen. Das heißt, dass ein Teil der Funktionalität durch Microkernel realisiert wird und weitergehende Teile einem anderen Muster folgen. Bekannte Implementierungen sind L4, Mach (Teil einiger BSD Systeme), Windows NT Kernel und GNU/Hurd. Daneben gibt es noch Linuxdistributionen, die einen Microkernel anstatt des monolithischen Linux Kernels einsetzen. Dies sind unter anderem MkLinux und spezielle echtzeitfähige Linuxsysteme. Durch die Adapter verhält sich der Microkernel eines solchen Systems von den Aufrufen her wie ein gewöhnlicher Linuxkernel.

Microkernel finden sich auch in weiteren Systemen. Er ist bei Serversystemen beliebt, der Mikrokern realisiert die Kernfunktionalitäten, die durch interne Server erweitert werden. Die externen Server sind dann Module, die den Server um weitere Funktionalitäten ergänzen. Daher finden sich Microkernel auch im Apache HTTP Server und in Java Enterprise Servern wie JBoss. Diese Server zeichnen sich durch eine große Anzahl an Modulen aus (externen Servern), mit der die Funktionalität stark erweitert werden kann.

8. Patterns und Einsatz in funktionale oder imperativen Sprachen

Da ein Muster die Abstraktion einer Lösung darstellt stellt sich generell die Frage, ab wann solch eine Abstraktion als Muster zu werten ist. Meist ist ein gewisser Grad an Abstraktion Vorraussetzung für eine solche Zuordnung.

Auf niedriger Abstraktionsebene haben sich die Idiome als Mini-Muster durchgesetzt.

Nicht-Objektorientierte Muster können nicht in einem UML-Diagramm dargestellt werden und es ist schwierig, denselben Grad an Komplexität zu erreichen. Ein Idiom wäre jedoch nicht komplex genug um einem funktionalen Muster gerecht zu werden. Diese befinden sich deshalb meist zwischen beiden Modellen.

Besonders im Bereich der funktionalen logischen Programmiersprachen sind einige bekanntere Muster wie zum Beispiel der „beschränkte Konstruktor“ („Constrained Constructor“) oder die Inkrementelle Lösung („Incremental Solution“) zu verzeichnenl.13.

13 http://web.cecs.pdx.edu/~antoy/flp/patterns/ , http://www.informatik.uni-kiel.de/~mh/papers/FLOPS02.pdf

21

Auch in der nicht-logischen funktionalen Programmiersprache kennt man einige Entwurfsmuster14 wie zum Beispiel das „Function Object“ oder das „Lazy Object“, welches alle Berechnungen bis zum spätmöglichsten Zeitpunkt aufhebt und erst dann ausführt.

Johannes Waldmann stellt in einer 2005 veröffentlichten Rede die These auf, dass OO-Entwurfsmuster trotz einer guten Orientierung und Abstraktionen im Rahmen der OO-Programmierung bieten, oft eine klarere funktionale Lösung existiere.15

Die imperative Programmierung muss währenddessen bislang ohne Entwurfsmuster auskommen.

9. Antipatterns (Antimuster)

Im Gegensatz zu Patterns sind Antipatterns Muster, die zwar auf den ersten Blick als gute Lösung erscheinen könnten, bei genauerem Hinsehen aber mehr Nach- als Vorteile bringen.

Diese Art der Muster wurde vor allem erforscht und dokumentiert, um gegen geläufige Fehler Prävention zu leisten, indem man sie klar identifiziert und einen Lösungsweg bzw. das passende Entwurfsmuster vorgibt.

9.1. Design-Antipatterns

9.1.1. Gott-Objekt

Eines der bekanntesten Beispiele für Entwurfs-Antimuster hierfür ist das Gott-Objekt, auch bekannt unter den Namen „Big Hairy Object“ und „Blob“. Wie der Name schon verrät, handelt es sich hierbei um eine Klasse, in der die objektorientieren Möglichkeiten nur suboptimal ausgenutzt wurden – und welche eine Vielzahl an Methoden beinhaltet, die offensichtlich gut in die entsprechenden, meist schon vorhandenen Objekte aufgeteilt werden können.

9.1.2. Goldener Hammer

Als besonders kniffliges Antipattern gilt der goldene Hammer. Er besagt, dass es auch als Antipattern gilt, wenn man versucht, alle Probleme mit einem einzigen (wohlgemerkt an sich positivem) Pattern zu „erschlagen“.

14 http://www.mm.informatik.tu-darmstadt.de/~kuehne/tfps/fps-sans-escher.pdf ab S.85 15 [Wa05], S. 5. letzter Teil

22

9.2. Programmierungs-Antipatterns

9.2.1. Zwiebel

Anstatt alten Code zu nutzen oder zu erweitern wird neuer Code einfach wie eine neue Schicht darüber gelegt. Dies kann häufig gesehen werden, wenn ein Programmierer den Code nicht selbst geschrieben hat und ihn deshalb nicht verstehen kann oder will. So entstehen viele Versionen und letztendlich ein Zwiebel-System.

9.2.2. Lavafluss

Ein Lavafluss besteht aus „totem“ Quelltext, der nicht entfernt wurde, so wie ein Lavastrom zu einem bestimmten Zeitpunkt abkühlt und erhärtet. Anstatt den Code zu löschen wird immer mehr Code außen herum gebaut.

9.3. Sonstiges

Interessanterweise beschränken sich die Antipatterns nicht nur auf den Programmcode und noch nicht einmal auf die Softwareentwicklung, auch wenn sie wahrscheinlich aus diesem Bereich hervorgingen. So findet sich als Teil der Team-Antipatterns zum Beispiel auch der „Doppelgänger“. Es beschreibt das Problem, dass eine Person mit einem Manager oder Kollege eine bestimmte Zeit gut und effizient zusammenarbeiten kann. Doch daneben reagiert der Kollege oder Manager bösartig und tritt unvernünftig auf.

Des Weiteren existieren unter anderem auch Projektmanagement-Antipatterns und Organisations-Antipatterns.16

10. Programmiersprachen mit eingebauten Mustern

Eines der interessantesten Beispiele für in Programmiersprachen integrierte Patterns stellt Smalltalk dar.

Insbesondere das Model-View-Controller-Muster (MVC) wurde durch Trygve Reenskaug für Smalltalk das erste Mal beschrieben und gilt heute als Standard für die Entwicklung eines Softwaresystems. Dieses Muster trennt die Daten („Model“) von der Darstellung („View“) und den ändernden Instanzen („Controller“).

Hier kommt auch schon ein weiteres Muster ins Spiel: Um die Daten in der Darstellung immer aktuell zu halten wird das Observer-Muster eingesetzt.

16 weitere Literatur [Br98], [Br99] und [Br00]

23

Des Weiteren finden sich in Smalltalk zum Beispiel Anwendungen des Strategy- und des Compositemusters.

11. Softwareunterstützung am Beispiel von StarUML

Um den täglichen Einsatz von Design-Patterns zu erleichtern, ist in einigen UML-Case-Tools eine Pattern-Unterstützung integriert. In der Regel führen die Programme Pattern-Kataloge mit, in den auch schon bestimmte Patterns eingepflegt sind (z.B. die GOF-Patterns). Allerdings ist die grundsätzliche Handhabung der verschiedenen Tools teilweise noch etwas verbesserungsbedürftig.

Um die Vorgehensweise anhand eines Beispieles aufzuzeigen, wurde das UML-Programm StarUML gewählt. StarUML ist ein Open-Source-UML-Case-Tool für Windows-Plattformen. StarUML bietet unter anderem:

• UML 2.0-Unterstützung: UML ist ein sich standing weiterentwickelnder Standard der OMG (Object Management Group) und wird von StarUML in der derzeit aktuellsten Version 2.0 unterstützt.

• MDA (Model Driven Architecture)

• Eine Plug-in Architektur

• Pattern-Support

24

11.1. Einbinden von neuen Patterns in das bestehende Modell

Um neue Patterns, und damit auch neue Klassen, in ein bestehendes UML-Projekt einbinden zu können, bietet StarUML den „Apply pattern“-Dialog. Dort können bestehende Patterns ausgewählt und in das aktuelle Modell hinzugefügt werden.

Abbildung 10: Der "Apply pattern"-Dialog

Ist das passende Pattern gewählt, können die Namen der neuen Klassen angepasst und abschließend in das Diagramm übernommen werden.

Abbildung 11: Ein aus dem Pattern-Katalog übernommenes Pattern

25

11.2. Übernehmen von Patterns in bestehende Modell

Wird auf bereits bestehende Modelle aufgesetzt, kann auch später ein Pattern auf die Klassen angewendet werden. Dies kann zum Beispiel der Fall sein, wenn nach der Modellierung erkannt wird, dass der Einsatz von einem Entwurfsmuster positiv ist.

Um die bestehenden Klassen in das Pattern einzubinden, werden diese in der Parametrisierung des Patterns angegeben.

Abbildung 12: Übernehmen von Patterns in bestehende Modell

26

Ist dieser Schritt abgeschlossen, baut sich das Modell erneut auf bzw. werden die betroffenen Klassen im Modell aktualisiert.

Abbildung 13: Ein erneut generiertes Modell

11.3. Code-Erzeugung

StarUML ist anschließend auch in der Lage, den Quellcode des erzeugten Modells zu generieren. Dazu können verschiedene Profile eingestellt werden. Diese können dann C++, C# und Java-Code erzeugen.

27

12. Fazit

Die Sammlung und Verwendung von Klassen und Bibliotheken erlauben es, verschiedene Teilfunktionen und Algorithmen wieder zu verwenden. Jedoch kann mit diesen Bibliotheken keine Entwurfsentscheidungen wieder verwendet werden. Software Patterns ermöglichen, Entwurfsideen und Strukturen über das konkrete Softwareprojekt hinaus festzuhalten und zu beschreiben.

Die Muster können dann bei ähnlichen Problemstellungen immer wieder verwendet werden. Musterkataloge bilden dabei eine strukturierte Sammlung von Softwaremuster für verschiedenste Problemstellungen. So kann ein Anwender auf diese Sammlung während der Analyse oder des Entwurfs einer Software zurückgreifen und diese Muster an die konkrete Problemstellung anpassen. Durch die vielfache Erprobtheit der Mustersammlungen muss das Rad nicht immer neu erfunden werden. Dies spart Zeit und gibt eine gewisse Garantie, dass der Entwurf auch funktioniert, was durch eigene Ideen nicht immer gewährleistet ist.

Es gibt zwei Arten von Mustern. Die einen sind die Architekturmuster, welche die gesamte Systemarchitektur einer Software beschreiben. Ein Beispiel dafür ist die Mehrschichten Architektur. Im Gegensatz dazu gibt es die Entwurfsmuster, die für Teilprobleme der Software angewendet werden, etwa der Observer, der Änderungen in der Tabellenkalkulation überwacht. Daher finden sich in einer Anwendung mehrere Muster, die verschiedene Probleme behandeln.

Sehr bekannte Muster sind vielen Softwareentwicklern bekannt. Daher erhöhen Muster das Verständnis für die Funktionsweise der Software. Durch Nennung eines Musters kann man schon den groben Aufbau der Software abschätzen und erleichtert somit die Diskussion über Entwurfsaspekte.

Die Muster sind abstrakt gehalten, damit sie für eine ganze Problemklasse anwendbar sind. Daher muss ein Muster immer an den gewünschten Anwendungsfall angepasst werden. Oft gibt es mehrere Muster, die für die Anwendung passen. Daher muss sorgfältig geprüft werden, welches Muster eingesetzt werden soll. Grundsätzlich hat ein Muster gewisse Vorteile für Teilaspekte, bringt jedoch immer Nachteile in anderen Bereichen mit.

Natürlich gewährleisten Muster nicht automatisch eine gute Softwarequalität. Die abstrakten Muster müssen erst konkretisiert werden. So kann ein gleiches Muster in zwei Anwendungen völlig anders umgesetzt worden sein. Ein Architekturmuster alleine sagt über die Qualität noch gar nichts aus. Es beschreibt nur den Rahmenaufbau einer Software. In der Software ist noch viel Freiraum für Chaos. Gefährlich ist aber auch das Überstrapazieren von Mustern, also dass für fast jedes Problem ein Muster gesucht wird.

28

Literaturverzeichnis

[Bu98] Buschmann et al.: Pattern-orientierte Software-Architektur . Ein Pattern-System. Addison-Wesley. ISBN 3-8273-1282-5

[Bu96] Buschmann, F. et al.: Pattern-Oriented Software Architecture - A System of Patterns, John Wiley & Sons, New York, 1996

[Kü99] Kühne, Thomes: A Functional Pattern System for Object-Oriented Design . Verlag Dr. Kovac; Auflage: 1. Aufl. (1999); ISBN: 3860647709

[Wa05] Waldmann, Johannes: Objektorientierte Entwurfsmuster in der Funktionalen Programmierung. HTWK Leipzig, Juni 2005. Weblink: http://www.imn.htwk-leipzig.de/~waldmann/talk/patterns.8.ps

[Sk00] Stephan Kohlrausch, Türen in den Ecken, Bauhaus-Universität Weimar, April 2000 (Sekundärquelle für Alexander Christophers Patternsammlung) http://www.uni-weimar.de/architektur/InfAR/lehre/Entwurf/Patterns/196/ca_196_d.html

[Ez99] Ezgarani, O.: The Magic Format – Your Way to Pretty Books, Noah Sons, 2000.

[JioA] http://c2.com/ppr/wiki/JavaIdioms/JavaIdioms.html, Abruf am 28.11.07

[Sc96] Software Patterns, Commun. ACM, October 1996, 36-39

[Br98] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Dr. Thomas J. Mowbray, Theresa Hudson (ed).) (1998). AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis. John Wiley & Sons, ltd. ISBN 0-471-19713-0.

[Br99] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Scott W. Thomas, Theresa Hudson (ed).) (1999). Anti-Patterns and Patterns in Software Configuration Management. John Wiley & Sons, ltd. ISBN 0-471-32929-0

[Br00] Brown, William J.; Raphael C. Malveau, Hays W. "Skip" McCormick, Scott W. Thomas, Theresa Hudson (ed).) (2000). Anti-Patterns in Project Management. John Wiley & Sons, ltd. ISBN 0-471-36366-9

Abbildungsverzeichnis

Abbildung 1 - Klassenadapter (UML-Diagramm)................................................................9

Abbildung 2 - Objektadapter (UML-Diagramm)................................................................11

Abbildung 3 - Fassade (UML-Diagramm) ..........................................................................12

Abbildung 4 - Kommandomuster (UML-Diagramm) ........................................................13

Abbildung 5 - Abstrakte Fabrik (UML-Diagramm) ...........................................................14

Abbildung 6: Struktur eines Microkernels .........................................................................18

Abbildung 7: Klassendiagramm...........................................................................................20

Abbildung 8: Verhalten bei Zugriff von außen...................................................................21

Abbildung 9: Dynamische Aspekte .....................................................................................22

Abbildung 10: Der "Apply pattern"-Dialog ........................................................................27

Abbildung 11: Ein aus dem Pattern-Katalog übernommenes Pattern ...............................27

Abbildung 12: Übernehmen von Patterns in bestehende Modell.......................................28

Abbildung 13: Ein erneut generiertes Modell .....................................................................29

Tabellenverzeichnis

Tabelle 1: Beispiel Architekturmuster...................................................................................5