Softwarearchitektur - Metadaten, Systeme und Frameworks

Softwarearchitektur - Metadaten, Systeme und Frameworks 

Einleitung 

Die Systemarchitektur heutiger Online-Anwendungen, muss den Anforderungen nach  vernetzter Kommunikation und globaler Verfügbarkeit Rechnung tragen. Diese Anforderungen konnten durch große, monolithische Systeme nur schwer erfüllt werden, da sie propriertäre und abgeschlossene Systeme waren. Durch die Verbesserung der Netztechnologie in der 1980er Jahren sowie die gleichzeitige Verbesserung des Preis-Leistungsverhältnisses von  Prozessoren und Hardware, konnten neue verteilte  Systemarchitekturen entwickelt werden. Heutige Systemarchitekturen zeichnen sich dadurch aus, dass sie aus verschiedenen Komponenten bestehen und über Datenkommunikationsverbindungen miteinander Informationen austauschen. Die Verteilung der Systemkomponenten eines Informationssystems findet auf drei Ebenen statt, der Hardwareebene, der Betriebssystemebene und der Anwendungsebene.

Abb.  1- Systemebenen eines Informationssystems

Die Verteilung von Komponenten ist ein zentrales Entwurfs- und Implementierungsparadigma von Systemarchitekturen und ist zentraler Bestandteil von Technologieplattformen wie Java JEE und Microsoft .NET. Im Rahmen der technologischen Entwicklung der letzten Jahrzehnte entstanden neue Programmiersprachen und Technologien.

Die folgende Ausarbeitung soll die wichtigsten Bestandteile aktueller Systemarchitekturen und Technologien darstellen, dazu gehören:

• Systemarchitektur im Bereich Internet- und Mobile Computing Anwendungen
• Technologieplattformen und Frameworks
• Technologiekomponenten und Programmiersprachen

Modelle und Metadaten

Im Rahmen der Ausarbeitung werden in verschiedenen Bereichen auf Modelle referenziert wie unter anderem Prozessmodelle oder Datenmodelle. Nach (Stachowiak, 1973) können Modelle durch drei Hauptmerkmale definiert werden:

1. Das Abbildungsmerkmal steht dafür, dass Modelle natürliche oder künstliche Objekte darstellen, die selbst von Modellen abgeleitet sind.
2. Das Verkürzungsmerkmal steht für die Abstraktion des Originals, um nur auf die für einen Sachverhalt wichtigen Eigenschaften eines Objektes zu fokussieren.
3. Pragmatisches Merkmal steht dafür, dass Modelle nicht eins zu eins ihren Originalen zugeordnet werden können. So können Modelle nur einen Teilbereich des Originals abdecken, nur in bestimmten Zeitintervallen gültig sein sowie tatsächlichen oder gedachten Einschränkungen unterliegen[1].

In diesem Zusammenhang stehen auch die Begriffe Metamodell und Metadaten. Der Begriff Meta (griech.: „darüber hinaus“) steht für etwas Übergeordnetes. Metadaten beschreiben ein Objekt und sind damit „Daten über Daten“. Eine strukturierte Ablage von Metadaten auf elektronischen Medien erlaubt die elektronische Auswertung der Daten[2]. Ein Metamodell ist ein übergeordnetes Modell, welches die Regeln und die Grammatik für den Modellentwurf vorgibt. Wird ein Modell erstellt, eine Instanz des Metamodells gebildet, so baut dieses Modell auf den Regeln und Strukturen auf, die im Metamodell festgelegt sind[3].

Systeme und Systemkomponenten

Modelle werden unter anderem verwendet um Systeme zu beschreiben. Nach IEEE wird ein System allgemein wie folgt definiert:

“A system is a collection of components organized to accomplish a specific function or set of functions.”(IEEE Standard 610.12-1990)

Eine mehr Software orientierte Definition nach Rumbaugh lautet wie folgt:

“A system is a collection of connected units organized to accomplish a purpose. A system can be described by one or more models, possibly from different viewpoints. The complete model describes the whole system.”

Vogel beschreibt drei entscheidende Eigenschaften(Vogel, 2009 S. 59):

• Ein System ist eine Einheit, die aus wechselseitig interagierenden Teilen respektive Systembausteinen besteht….
• Ein System besitzt eine Systemgrenze die es von seiner Umwelt trennt
• Ein System existiert immer zur Erreichung eines Ziels

Dabei kann ein System aus Systembausteinen bestehen und selbst ein Systembaustein sein. Liegt eine hierarchische Ordnung von Systembausteinen vor, werden die Systembausteine auch Subsysteme genannt. Ein Systembaustein wird auch als Komponente bezeichnet, im Sinne eines in sich geschlossenen Bausteins einer Systemarchitektur[8].

Die IEEE Spezifikation (IEEE Standard 610.12-1990) definiert die Systemarchitektur als „organizational structure of a system or component”. Dabei ist eine Komponente ein abgeschlossener Teil eines Systems, der eine definierte Schnittstelle nach außen aufweist.  Der Architekturentwurf beschreibt den Aufbau und die Realisierung der Systemarchitektur auf Basis von Komponenten und Konnektoren. Nach IEEE (IEEE Standard 610.12-1990) sind  Konnektoren Verbindungen zwischen Komponenten.

Elemente der Softwarearchitektur sind:

• Komponenten
• definieren den Ort von Berechnungen, z.B. Filter, Datenbanken, Objekte, Server, Klienten usw.
• Beziehungen (Konnektoren)
• definieren die Interaktion der Komponenten, z.B. Funktionsaufruf, Pipe, Event usw.
• Eigenschaften
• definieren Vorgaben und Beschränkungen für Analyse und Design, z.B. Vorbedingungen, Qualitätsmerkmale usw.

Ziele der Systemarchitektur ist es:

·       Grundlegenden Entscheidungen für Entwurf (Design) und Implementierung des Systems festzulegen.

·       Die Kommunikation und Gesprächsablauf der Systembeteiligten (engl. Stakeholder) festzulegen.

·       Sie ist die Grundlage für die Erreichung funktionaler und qualitativer Merkmale des Systems.

Der Aufbau einer Systemarchitektur folgt oft wiederkehrenden Mustern[9]. Ein solches  Architekturmuster oder auch Architekturstil genannt, ist wiederverwendbar und auf andere Systeme übertragbar.

Softwaresystemarchitektur kann nach Abstraktionsgrad in verschiedene Architekturebenen eingeteilt werden:

Meta-Architektur

• hierzu zählt z.B. SOA als konzeptionelles Architekturmodell
• Makro-Architektur
• wird auf einem abstrakten Level definiert hierzu zählen die Architekturmuster wie z.B. die schichtenbasierte Softwarearchitektur (engl. Layer).
• Mikro-Architektur
• niedriger Abstraktionsgrad, z.B. Entwurfsmuster (Vorstufe für eine Implementierung)

Rahmenwerke (Frameworks)

Die IEEE Spezifikation (IEEE Standard 610.12-1990) definiert die Systemarchitektur als „organizational structure of a system or component”. Dabei ist eine Komponente ein abgeschlossener Teil eines Systems, der eine definierte Schnittstelle nach außen aufweist. Der Entwurf einer Softwaresystemarchitektur beschreibt den Vorgang und das Resultat des Softwaresystem Entwurfs (IEEE Standard 610.12-1990) und wird nach IEEE wie folgt definiert:

“The process of defining the architecture, components, interfaces, and other characteristics of a system or component and the result of that process”.(IEEE Standard 610.12-1990)

Im Rahmen des Grobentwurfs einer Softwareentwicklung muss ein Architekturentwurf des Softwaresystems erstellt werden (engl. Architectural Design). Ein Rahmenwerk (engl. Framework) ist ein Teil einer Softwaresystemarchitektur. Vogel definiert ein Framework als ein

„teilweise komplettes Software-System (oder Subsystem), das instanziiert werden soll. Somit definiert ein Framework eine Architektur für eine Familie von (Sub-) Systemen und stellt die elementaren Bausteine der Architektur zur Verfügung.“(Vogel, 2009 S. 160)

Aus Sichtweise der Softwarearchitektur sind Rahmenwerke ein Teil einer Systemarchitektur und basieren auf Klassenbibliotheken.

Nach (Balzert, 2000) können Klassenbibliotheken in zwei Arten unterschieden werden:

■         »Einfache« Klassenbibliotheken und

■         Rahmenwerke (frameworks).

Dabei üben »einfache« Klassenbibliotheken nur geringen Einfluss auf die Anwendungsarchitektur aus. Das wichtigste Ziel ist die Wiederverwendung von Quellcode. Demgegenüber stehen Klassenbibliotheken welche entscheidenden Einfluss auf die Softwarearchitektur haben, diese Bibliotheken stellen ein Rahmenwerk für die zu erstellende Software dar. Nach Gamma definiert sich ein Rahmenwerk wie folgt (Gamma, et al., 1995):

„Ein Rahmenwerk (framework) ist ein durch den Software-Entwickler anpassbares oder erweiterbares System kooperierender Klassen, die einen wiederverwendbaren Entwurf für einen bestimmten Anwendungsbereich implementieren. Es besteht aus konkreten und - insbesondere -aus abstrakten Klassen, die Schnittstellen definieren. Die abstrakten Klassen enthalten sowohl abstrakte als auch konkrete Operationen. Im Allgemeinen wird vom Anwender des Rahmenwerks erwartet, dass er Unterklassen definiert, um das Rahmenwerk zu verwenden und anzupassen. Diese selbstdefinierten Unterklassen empfangen Botschaften von den vordefinierten Rahmenwerk-Klassen nach dem Hollywood-Prinzip »Don't call us, we'U call you«“(Gamma, et al., 1995)

Unified Modelling Language

Die Unified Modelling Language ist allgemein anerkannte Notation zur Modellierung von Softwaresystemen[4] und aber auch anderen technischen Systemen (z.B. Embedded Real Time Systeme[5]). Die UML Notationen ist eine von der „Object Management Group“[6] (OMG) initiierter Standard und

„dient zur Modellierung, Dokumentation, Spezifizierung und Visualisierung komplexer Softwaresysteme, unabhängig von deren Fach- und Realisierungsgebiet. Sie liefert die Notationselemente gleichermaßen für die statischen und dynamischen Modelle von Analyse, Design und Architektur und unterstützt insbesondere objektorientierte Vorgehensweisen.“(Rupp, et al., 2007 S. 12)

Die in der Fallstudie verwendeten Modelle[7] sind u.a. Anwendungsfalldiagramme (engl.: use case diagram), Aktivitätsdiagramme (engl.: activity diagram), Klassendiagramme (engl.: class diagram), Komponentendiagramme (engl.: component diagram) und Verteilungsdiagramme (engl.: deployment diagram).

Autor: Friedhelm Feisel

---

[1] Siehe auch (Stachowiak, 1973).

[2] Ein Zitat von Tim Burners-Lee dem Erfinder des World Wide Web (WWW) beschreibt Metadaten wie folgt: „Metadaten sind maschinenlesbare Informationen über elektronische Ressourcen und andere Dinge“.

[3] Siehe auch Völter, M., & Stahl, T. (2006). Model-Driven Software Development : Technology, Engineering, Management . New York, NY : Wiley, J ., Seite 21.

[4] Siehe auch (Rupp, et al., 2007 S. 12 ff.).

[5] Siehe auch (Hruschka, et al., 2002).

[6] Die Object Management Group (OMG) ist ein Industriekonsortium mit über 800 Mitgliedern mit der Aufgabe herstellerneutrale Standards zu erstellen und zu pflegen.

[7] Für eine detaillierte Beschreibung und Definition der Modelle siehe (Object Management Group, Inc., 2010).

[8] Die Beschreibung einer Komponente geht zurück auf (Vogel, 2009 S. 161), Kapitel „6.2.3 Komponentenorientierung“.

[9] Siehe auch Christopher Alexander, Architekt und Systemtheoretiker (Alexander, 1977).

Literaturverzeichnis

Alexander, Christopher. 1977. A Pattern Language. New York : Oxford University Press, 1977.

Balzert, Helmut. 2000. Lehrbuch der Softwaretechnik : Basiskonzepte und Requirements-Engineering. Heidelberg : Spektrum, Akad. Verl., 2000. Bd. 2. Aufl.

Bundschuh, Manfred. 2000. Aufwandschätzung von IT-Projekten : [Zeit und Kosten von Anfang an im Griff haben ; Planungssicherheit durch zuverlässige Schätzung ; function point und andere Methoden] . Bonn : MITP, 2000. 3-8266-0534-9.

Deck, Klaus-Georg und Neuendorf, Herbert. Java-Grundkurs für Wirtschaftsinformatiker. s.l. : Friedr.Vieweg & Sohn Verlag. 978-3-528-05915-6.

Gamma, Erich, et al. 1995. Elemente wiederverwendbarer objektorientierter Software. s.l. : Addison Wesley in Pearson Education Deutschland GmbH, 1995.

Gibbs, R. Dennis. 2006. Project management with the IBM Rational Unified Process : lessons from the trenches. Upper Saddle River : Pearson Education, Inc./IBM Press, 2006. 0-321-33639-9.

Gunnerson, Eric. 2000. C# Die neue Sprache für Microsofts .NET-Plattform. Bonn : Galileo Press, 2000. 978-3898421072 .

Hruschka, Peter und Rupp, Chris. 2002. Agile Softwareentwicklung für embedded real time systems mit der UML. München; Wien : Hanser , 2002. 3-446-21997-8 .

IBM Corporation (DEV475). 2004. DEV475 Mastering Object-Oriented Analysis and Design with UML 2.0:Student Manual, Volume 1:Version 2004.06.00. [Dokument] s.l. : International Business Machines Corporation (Rational University), 2004.

IEEE Computer Society;IEEE Std 1061-1998. 1998. IEEE Standard for a Software Quality Metrics Methodology - IEEE Std 1061-1998. http://standards.ieee.org/findstds/standard/1061-1998.html. [Online] 08. 12 1998. [Zitat vom: 21. 10 2011.] http://standards.ieee.org/findstds/standard/1061-1998.html. ISBN 0-7381-1059-6.

IEEE Standard 610.12-1990. IEEE Standard 610.12-1990.

Jacobson, Ivar, Booch, Grady und Rumbaugh, James. 1999. The unified software development process . Reading, Mass : Addison-Wesley, 1999. 0201571692.

Jendrock, Eric, et al. 2012. The Java EE 6 Tutorial. [Online] 01. 04 2012. [Zitat vom: 30. 04 2012.] http://docs.oracle.com/javaee/6/tutorial/doc/index.html.

Kruchten, Philippe. 1995. Architectural Blueprints—The "4+1" View Model of Software Architecture. IEEE Software. 1995, Bd. 12, 6.

Langer, Thorsten und Reiberg, Daniel. 2006. J2EE und JBoss. Verteilte Enterprise Applikationen auf Basis von J2EE, JBoss & Eclipse. Grundlagen und Profiwissen. s.l. : Hanser, 2006. 978-3446405080.

Münz, Stefan. 2007. SELFHTML: Version 8.1.2 vom 01.03.2007. http://de.selfhtml.org/. [Online] SELFHTML e.V., 01. 03 2007. [Zitat vom: 04. 05 2012.] http://de.selfhtml.org/intro/technologien/html.htm.

Object Management Group, Inc. 2010. Documents associated with UML Version 2.3. [Online] Object Management Group, Inc., 04. 05 2010. [Zitat vom: 07. 09 2011.] http://www.omg.org/spec/UML/.

Piwinger, Boris. 2001. Kommunikation im Internet. Kommunikationsmanagemen . Kommunikationsmanagement, Bentele, Günter / Piwinger, Manfred / Schönborn, Gregor (Hrsg), 2001, Bde. Luchterhand, 2001 ff. Loseblattwerk, 3. Ergänzungslieferung September 2002.

Rupp, Chris, Queins, Stefan und Zengler, Barbara. 2007. UML 2 glasklar : Praxiswissen für die UML-Modellierung. München; Wien : Hanser, 2007. 978-3-446-41118-0.

Schmidt, Douglas, et al. 2002. Pattern-orientierte Softwarearchitektur. Heidelberg : dpunkt.verlag GmbH, 2002. 3-89864-142-2.

Stachowiak, Herbert. 1973. Titel Allgemeine Modelltheorie. Wien, New York : s.n., 1973. 3-211-81106-0.

Vogel, Oliver. 2009. Software-Architektur : Grundlagen - Konzepte - Praxis. Heidelberg : Spektrum, Akad. Verl. , 2009. 978-3-8274-1933-0.

Multithreading Ausblick - "What comes after the free lunch?"

Multithreading Ausblick - "What comes after the free lunch?"

Microsoft .NET 4 und Sprachunterstützung für parallele Verarbeitung

Die Anforderungen an die Softwarearchitektur Mehrprozessorsysteme zu unterstützen rückt immer stärker in den Vordergrund. Das gilt umso mehr für Anwendungen welche die Simulation von virtuellen Welten umsetzen. Eine optimale Auslastung der Prozessorhardware muss gewährleistet sein, möchte man den die vielfältigen Aufgaben wie 3D Grafik, physikalische Simulation, Kollisionsdetektion und Künstliche Intelligenz in einer Anwendung miteinander vereinen.

 

Noch ist die Entwicklung von Algorithmen für Mehrprozessorarchitekturen kompliziert. Die Softwareentwicklung nebenläufiger Systeme verlangt tiefgehende Kenntnisse der jeweiligen Rechnerarchitektur und Threading Idiome. Um dies zu vereinfachen entstehen zurzeit neue Werkzeuge und Spracherweiterungen im Microsoft .NET Umfeld. Dazu gehören die Task Parallel Library (TPL) Bibliothek, PLINQ und Concurrency and Coordination Runtime.

 

Task Parallel Library (TPL)

Die Task Parallel Library (TPL) soll die Entwicklung für Mehrkernprozessoren unter .NET Framework erleichtern und beschleunigen. Intelligente neue Code-Kontrollstrukturen (wie z.B. Parallel.For), sollen automatisch Mehrkernprozessoren ausnutzen, d.h. der Code passt sich zur Ausführungszeit an die ausführende Umgebung an.

Beispiel für das klassische For Schleifenkonstrukt:

 

for (int i = 0; i < 100; i++) {

  a[i] = a[i]*a[i];

}

Beispiel für das neue parallele Schleifenkonstrukt Parallel.For:

 

Parallel.For(0, 100,

delegate(int i) {

a[i] = a[i]*a[i];

}

);

 

Das Parallel.For kann genutzt werden um Aufgaben zu parallelisieren. Im vorliegenden Beispiel sollen alle Zahlen des Arrays quadriert werden. Dazu wird die Berechnung für das Parallel.For in eine Delegate Instanz verschoben, welches mittels einer anonymen Klasse erzeugt wird und die Ausführung der Berechnung übernimmt.

 

Das .NET Framework ist dann zur Ausführungszeit dafür zuständig die optimale Verteilung einer Parallel.For Iteration auf die Prozessorhardware vorzunehmen. Diese können dann parallel auf mehreren Prozessoren ausgeführt werden. Auf einer Single Prozessor Maschine wird das Programm sequentiell ausgeführt.

PLINQ – Parallel Language Integrated Query

Die Language Integrated Query (LINQ) erlaubt es Mengenoperationen auf Datenkollektionen (u.a. Liste, Queue). Die parallele Variante PLINQ – Parallel Language Integrated Query unterstützt die nebenläufige Verarbeitung der Daten. Bei Bedarf können die Vorteile der Mehrprozessorhardware genutzt werden und die Ausführung der Mengenoperation auf mehrere Prozessoren verteilt werden.

Beispiel für einen LINQ basierten Zugriff auf eine Liste:

var query = from c in Customers where c.Name = “Smith”

select c;

Beispiel für einen PLINQ basierten Zugriff auf eine Liste:

 

var query = from c in Customers.AsParallel()

    where c.Name = “Smith”

select c;

 

Concurrency and Coordination Runtime (CCR)

Mit der Concurrency and Coordination Runtime (CCR) bietet Mircosoft eine weitere .NET Programmbibliothek für die asynchrone und nebenläufige Programmierung an. In CCR wird mit Hilfe asynchroner Methoden und einem Nachrichten basierten System Nebenläufigkeit implementiert. Dabei werden technische Details wie die Wahl des Threadmodells oder die Anzahl der Threads vor dem Entwickler verborgen. Die Arbeitspakete werden in Warteschlangen sogenannten »Ports« abgelegt. Diese werden dann von »Arbiter« Komponenten verarbeitet.

 

Ausblick für Systemarchitektur des Grafik-Engine Frameworks

Herb Sutter schrieb in seinem Artikel “The free lunch is over”:

 

"The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency.”(The Free Lunch Is Over, A Fundamental Turn Toward Concurrency in  Software, 2005)

 

Diese Erwartungshaltung kann als neue Anforderung an die Framework-Architektur formuliert werden. Das INSPIRE-XNA Framework soll in Zukunft verschiedene Mechanismen und Verfahrensweisen der künstlichen Intelligenz unterstützen, z.B. Optimierung auf Basis von evolutionären Methoden, Pfadsuche und andere Algorithmen der Künstlichen Intelligenz (engl. Artifical Intelligence) sollen implementiert werden.

 

Viele dieser KI-Algorithmen erfordern eine Umsetzung mittels nebenläufiger Programmierung, um die Gesamtperformanz des Frameworks nicht zu stark zu beeinträchtigen. Die Umsetzung der Algorithmen mit herkömmlichen Programmierverfahren (z.B. Thread-Klassen basiert), macht die Implementierung komplex und erschwert die Wartbarkeit des Codes. Hier könnten die genannten neuen Technologien wie TPL, PLINQ und CCR zum Einsatz kommen.

 

Durch die Abstraktion der nebenläufigen Idiome und Lösung von technischen Details wird die Umsetzung nebenläufiger Szenarien wesentlich erleichtert und die Programmierung vereinfacht. Dies ermöglicht eine ganz neue Generation von Softwareanwendungen, welche sich an die aktuelle und zukünftige Prozessorhardware anpasst und die Hardware-Ressourcen optimal ausnutzt.

 

Architektur- und Entwurfsmuster werden ihren Beitrag leisten und auf abstrakter Ebene Lösungen anbieten, um die funktionalen Anforderungen an die Software zu erfüllen. Schon gibt es eine ganze Reihe neuer Pattern (z.B. „Parallel Computing Pattern“) um Lösungen für wiederkehrende Problemstellungen nebenläufiger, bzw. paralleler Systeme anzubieten.

 

Autor: Friedhelm Feisel

 

Multithreading - Nebenläufigkeit und Systemarchitektur - Proactor basiertes Render Management

Multithreading und Systemarchitektur

Nebenläufigkeit und Systemarchitektur

Warum sollte sich Software-Systemarchitektur mit Nebenläufigkeit und paralleler Verarbeitung beschäftigen?

Moores Gesetz (Gordon Moore,1960) besagt das die Leistung der Prozessoren sich alle 18 Monate verdoppeln wird. Dieses Gesetz steht heute unter geänderten Vorzeichen. So setzen die Prozessor Hersteller weniger auf Beschleunigung und komplexere Prozessoren, sondern setzen mehrere CPUs in einem Chip ein. Die Gründe sind vielseitig, wie Hitze, Leistungsaufnahme oder physikalische Grenzen, d.h. weniger Energieverbrauch. Die neuen Mehrkernprozessoren sind kostengünstiger in der Herstellung und effizienter im Betrieb. Mehrkernprozessoren finden sich heute bei Servern, Desktop-PCs, Mobiltelefonen oder PDA. 

Dieser Entwicklung muss in der Softwareentwicklung Rechnung getragen werden. Oft sind die Anwendungen für Single Prozessor Umgebungen geschrieben, alle Berechnungsschritte und Prozesse laufen serialisiert ab. In den vergangenen Jahren wurden einige grundlegende Architekturmuster und Idiome für Mehrprozessor Architektur entwickelt. Ein Beispiel ist das Proactor-Architekturmuster welches in INSPIRE-XNA, einer eigenentwickelten Grafikengine, angewendet wird und weiter unten vorgestellt wird, zuvor einige Definitionen.

Nebenläufigkeit ist nach (Buschmann, et al., 2000 S. 19) definiert:

„Der Begriff Nebenläufigkeit (engl. Concurrency) bezeichnet eine »Familie« von Verfahrensweisen und Mechanismen, die es einem oder mehreren Ablauffäden (Thread) oder Prozessen ermöglichen, die ihnen zugeteilten Aufgaben gleichzeitig auszuführen.“

Dabei definiert sich ein Prozess wie folgt:

„Ein Prozess ist eine Ansammlung von Betriebsmitteln, die es erlaubt, Programminstruktionen auszuführen.“(Buschmann, et al., 2000 S. 19)

In der IT-Fachsprache wird der englische Begriff »Multithreading« verwendet, wenn die Programausführung mit mehreren Ablauffäden realisiert ist. Ein (Programm-) Ablauffaden (engl. Thread) ist wie folgt definiert:

„Ein Ablauffaden ist eine konkrete Folge von Programmschritten, die innerhalb eines Prozesses ausgeführt werden. Ein Ablauffaden verwaltet ebenfalls eine Reihe von Betriebsmitteln. Diese umfassen neben einem Befehlszähler auch einen Laufzeitkellerspeicher zur Verwaltung von Funktionsaufrufen, verschiedene Register sowie ablauffadenspezifische Daten.“(Buschmann, et al., 2000 S. 19).

David W. Bustard (Bustard, 1990) beschreibt Nebenläufigkeit und parallele Programme. Danach hat ein  »Nebenläufiges Programm« bei der Ausführung mehr als einen Handlungsfaden (Kontrollfluss). Er spricht in diesem Fall von »logischer Gleichzeitigkeit«. Dazu gehört das die Programme „potentiell“ parallel ausgeführt werden können oder auf einer CPU nacheinander, z.B. im Zeitscheibenverfahren.

Nach Bustard wird ein »Paralleles Programm« auf mehreren Prozessoren gleichzeitig ausgeführt. Dabei spricht man von „Daten-Parallelität“ wenn jedes Programm einen Teil der Daten zugewiesen bekommt. Bekommt jedes Programm einen Teil der Aufgaben zugewiesen liegt eine „Kontroll-Parallelität“ vor. Laufen die Programme gleichzeitig auf mehreren Rechnern oder CPU-Kernen ab spricht man von „physikalischer Gleichzeitigkeit“(Bustard, 1990)

Welche Vorteile hat ein Framework wie INSPIRE-XNA durch nebenläufige Methoden?

Zum einen verspricht die bessere Auslastung der Mehrkernprozessoren Leistungsvorteile bei der Programmausführung. Die Bereitstellung dedizierter Threads für die IO-Verarbeitung kann Latenzzeiten überbrücken. Zum einen können in Echtzeit Benutzereingaben verarbeitet werden zum anderen können parallele Threads mit weiteren Aufgaben betraut werden. Ein weiteres Beispiel sind Ausgaben auf der Grafikhardware, die IO-Operationen zwischen CPU, Hauptspeicher sowie GPU und Grafikartenspeicher stellen oft einen Flaschenhals dar, der mittels nebenläufiger Programmierung umgangen werden kann.

Multithreading Architektur - Proactor basiertes Render Management

Wie oben beschrieben können nebenläufige Verfahrensweisen für interaktive, grafische Anwendungen eingesetzt werden und große Vorteile bringen. Am Beispiel des Proactor Architekturmusters soll dieses verdeutlicht werden.

Situation und Anforderung: Die Hauptanwendungsschleife des INSPIRE-XNA Framework ruft bei jedem Durchlauf eine Update und eine Draw Methode (Rendering) auf. Die Update Methode ist für die Aktualisierung und das Fortschreiten der Objektzustände zuständig. Dazu kann unter anderem die Eingabedatenverarbeitung, physikalische Berechnungen, Kollisionsabfragen der Welt Objekte und anderes mehr gehören. Die Update Aktivitäten fasse ich unter dem Begriff »Simulation« zusammen.

Die Draw Methode (Rendering) ist dabei für die Aufbereitung der grafischen Daten, die Ausführung von Effekten (Shader) und die Darstellung auf der Grafikkarte zuständig. Dazu gehört auch die Übertragung (IO) der Daten zwischen Hauptspeicher der CPU und Grafikkartenspeicher der GPU. Bei dem Zugriff auf die Grafikkartenhardware kann es zu Wartezeiten kommen, trotzdem soll im Hintergrund der Update Mechanismus weiter Eingabedaten entgegennehmen und die Simulation aktualisieren. Wie können nun Update- und Rendering so entworfen werden, das Latenzzeiten überbrückt und eine optimale Auslastung des/der Prozessoren erreicht wird?

Die INSPIRE-XNA Architektur verwendet hierzu zwei (Haupt-) Threads, einen Thread für das Rendering und einen weiteren Thread um die Simulation fortzuführen. Jedem Thread steht ein aktueller Nachrichten Puffer (engl. Message Buffer) zur Verfügung, welcher die aktuellen Objektzustände speichert. Innerhalb der Update Routine wird ein Puffer gefüllt und mit aktuellen Informationen (z.B. Position, Orientierung) der Welt Objekte gefüllt.

Der Render Thread nimmt seinen Puffer und bringt die in im enthaltenen Welt Objekte zur Anzeige. Nach dem aktuellen Zeichenvorgang tauschen Update und Render Thread ihre Puffer aus. Im Idealfall läuft dieser Vorgang mit einer Frequenz von > 30 Hz, damit das Rendering eine störungsfreie (d.h. ohne Aussetzer bei dem Bildaufbau) Wiedergabe von dynamischen Szenen bieten kann.

Um den Anforderungen Rechnung zu tragen wurde das Proactor Muster (Buschmann, et al., 2000 S. 237) für diesen Bereich angewandt. Das Proactor Muster wird vorrangig dort angewandt wo eine einzelne Komponente zahlreiche Anfragen parallel verarbeiten muss und eine hohe Performance gewährleistet werden muss. 

Im INSPIRE-XNA Framework ist diese Komponente das Update Management. Die Verwendung des Musters soll eine optimale Prozessorauslastung und ein Minimum an Latenzzeiten gewährleisten, da auf teure Kontextwechsel einer reinen Thread basierten Anwendung verzichtet wird.

Bild 28: Sequenzdiagramm Proactor 

Der Ablauf im Einzelnen:

1. Dabei initiiert ein Update Handler (auch engl. Proactive Initiator) eine asynchrone Operation, d.h. die Update Methoden werden asynchron gestartet und mit einer Callback Adresse versehen.
2. Die asynchrone Methode wird in einem Hintergrund Thread ausgeführt und die bearbeiteten Daten in einem Zwischenspeicher abgelegt.
3. Die Callback Adresse führt zu einem Ereignis-Demulitplexer (auch engl. Completion Dispatcher) Objekt.
4. Dieser Demultiplexer erhält dann den Callback Ausruf nachdem die asynchrone Operation beendet wurde.
5. Im Anschluss kann der Ereignis-Demultiplexer ein Completion Handler aufrufen, welcher die Ergebnisdaten aus dem Zwischenspeicher verarbeitet oder weiterleitet.

Bild 29: Klassendiagramm Proactor Pattern

Das Sequenzdiagramm des Update-Prozesses (Bild 30) zeigt wie eine Instanz des AsynchOperationProzessor einen asynchronen Methodenaufruf für ein Update durchführt. Im Hintergrund verarbeitet das .NET Framework, in Verbindung mit dem Betriebssystem, die aufgerufene Operation in einem eigenen Thread. Nach Ausführung wird die AsynchOperationProzessor.CallbackMethode() angesprungen und das Ergebnis in eine Instanz der CompletionEventQueue abgelegt.

Bild 30: Sequenzdiagramm DoubleBuffering Update Prozess Proactor

Die Proactor Instanz läuft in einem eigenen Thread und liest die CompletionEventQueue aus. Jeder CompletionEvent hat einen Bezeichner (Handle), welches auf einen CompletionEventHandler verweist. Dieser wird instanziiert und ausgeführt. Dieser Aufbau ermöglicht den hierarchischen Prozessaufbau von nebenläufigen Prozessen.

Autor: Friedhelm Feisel

 

Literaturverzeichnis

Alexander, Christopher. 1977. A Pattern Language. New York : Oxford University Press, 1977.

Balzert, Helmut. 2000. Lehrbuch der Softwaretechnik : Basiskonzepte und Requirements-Engineering. Heidelberg : Spektrum, Akad. Verl., 2000. Vol. 2. Aufl.

Bartle, Richard. 2003. Designing Virtual Worlds. s.l. : New Riders, 2003.

Beck, Kent. 1996. Smalltalk Best Practice Patterns. Upper Saddle River  : Prentice Hall, 1996.

Buschmann, Frank, et al. 2001. A System of Patterns: Pattern-Oriented Software Architecture: 1. West Sussex PO19 IUD. England : John Wiley & Sons, 2001.

Buschmann, Frank, et al. 1998. Pattern-orientierte Software-Architektur. Bonn : Addison-Wesley, 1998.

—. 2000. Pattern-orientierte Software-Architektur. Bonn : Addison-Wesley, 2000.

Bustard, David W. 1990. Concepts of Concurrent Programming. s.l. : Software Engineering Institute, Carnegie Mellon University, Curriculum Module SEI-CM-24, 1990.

Carter, Chad. 2008. Microsoft XNA Unleashed:Graphics and Game Programming XBox 360 and Windows. Indianapolis, Indiana : SAMS, 2008. 0-672-32964-6.

Center, Microsoft News. 2004. Microsoft: Next Generation of Games Starts With XNA. Microsoft News Center. [Online] 03 24, 2004. [Cited: 09 01, 2010.] https://www.microsoft.com/presspass/press/2004/mar04/03-24xnalaunchpr.mspx.

Coplien, J. 1994. Advanced C++ Programming Styles and Idioms. s.l. : Addison-Wesley, 1994.

Coplien, James. 1992. Advanced C++ Programming Styles and Idioms. 1992.

Eberly, David H. 2005. 3D game engine architecture - Engineering real-time applications with Wild Magic. Boston : Morgan Kaufman Publishers, 2005.

Endrei, Mark, et al. 2004. Patterns: Service-Oriented Architecture and Web Services. IBM RedBooks. s.l. : International Business Machines Corporation, 2004.

Fowler, Martin. 1997. Analysis Patterns. s.l. : Addison-Wesley, 1997.

Gamma, Erich, et al. 1995. Elemente wiederverwendbarer objektorientierter Software. s.l. : Addison Wesley in Pearson Education Deutschland GmbH, 1995.

—. 2009. Entwurfsmuster : Elemente wiederverwendbarer objektorientierter Software. s.l. : Addison Wesley in Pearson Education Deutschland GmbH, 2009. Vol. Ausgabe 1. Aufl.

Grootjans, Riemer. 2009. Xna 3.0 game programming recipes : a problem-solution approach. Berkeley, CA : Apress, 2009.

IEEE Standard 610.12-1990. IEEE Standard 610.12-1990.

J.Coplien, D.Schmidt, et.al. (eds.),. 1995. Pattern Languages of Program design: (PLoP 1-4). s.l. : Addison-Wesley, 1995.

Krzysztof Cwalina, Brad Abrams. 2009. Framework design guidelines : conventions, idioms, and patterns for reusable .NET libraries. Upper Saddle River, NJ  : Addison-Wesley, 2009. Vol. 2nd ed.

M.Shaw and Garlan, D. 1993. An Introduction to software architecture. In Advances in Software Engineering and Knowledge Engineering. Singapore : World Scientific Publishing Company, 1993.

Mary Shaw, David Garlan. 1996. Software Architecture: Perspectives on an Emerging. s.l. : Prentice Hall, 1996.

MSDN 2010, Microsoft. MSDN Library. MSDN. [Online] Microsoft. [Cited: 09 18, 2010.] http://msdn.microsoft.com/en-us/library/ff729722(VS.85).aspx.

Oestereich, Bernd. 2009. Analyse und Design mit UML 2.1 - Objektorientierte Softwareentwicklung. Oldenbourg : s.n., 2009. Vol. 9. aktualisierte und erw. Aufl.

Oliver Vogel, Ingo Arnold, Arif Chughtai, Markus Völter. 2009. Software-Architektur. Grundlagen - Konzepte - Praxis. Heidelberg : Spektrum Akademischer Verlag, 2009. Vol. 2. Auflage.

Ortega-Arjona, Jorge Luis. 2009. Patterns for parallel software design. Hoboken, NJ  : John Wiley, 2009.

Perry, Dewayne E. and L.Wolf, Alexander. 1992. Foundations for the Study of Software. s.l. : ACM SIGSOFT Software Engineering Notes, 1992.

Schmidt, Douglas C. 2002. Pattern-orientierte Software-Architektur: Muster für nebenläufige und vernetzte Objekte. Heidelberg : dpunkt-Verl., 2002. Vol. 1. Auflg.

The Free Lunch Is Over, A Fundamental Turn Toward Concurrency in Software. Sutter, Herb. 2005. 30(3), s.l. : Dr. Dobb's Journal, 2005, Vol. 30(3).

Thilmany, Christian. 2003. .NET Patterns: Architecture, Design, and Process . s.l. : Addison Wesley, 2003.

Timothy G. Mattson, Beverly A. Sanders, Berna L. Massingill. 2005. Patterns for parallel programming. Boston : Addison-Wesley, 2005.

Zhou, Marc Andre. 2009. Parallel Computing in .NET : Multicore-Programmierung von .Net 2.0 bis 4.0. Frankfurt, M. : Entwickler.press, 2009.