Was sind Komponenten?

Auf dem Weg zur Composite Component Architecture 2.0 hat sich gezeigt, dass die Architektur von Softwaresystemen aus den Bereichen Systemarchitektur, Softwarearchitektur und Softwaredesign besteht. Die vorangegangenen Episoden haben Letzteres, also das Softwaredesign, betrachtet. Die beschriebenen Muster, Praktiken und Techniken muss jeder Entwickler beherrschen. Somit steckt die detaillierteste Strukturierung auch im Werkzeugkasten des Architekten.Nun aber geht es um die gröbere Struktur der Anwendungen: die Komponenten, aus denen ein Softwareprojekt besteht. Damit verlässt diese Kolumne die zuvor ausführlich behandelte Ebene des Softwaredesigns und taucht in das Thema Softwarearchitektur ein.

Was ist eine Komponente?

Bereits seit den ersten Tagen der professionellen Softwareentwicklung haben verschiedene Fachleute versucht, den Begriff der Komponente im Kontext der Softwareentwicklung genauer zu erklären [1]. Jede dieser Definitionen betrachtet den Begriff allerdings aus einem bestimmten Kontext heraus. Daher folgt nun ein möglichst neutraler Versuch.Eine Komponente ist eine in sich geschlossene Gruppe von Unteraufgaben, die eine Aufgabe gemeinsam zu lösen versuchen. Die Komponente wird durch eine fest definierte Schnittstelle aufgerufen und ruft wieder andere Komponenten auf, ebenfalls über fest definierte Schnittstellen.Wenn Sie an das Wort Komponenten denken, so werden Sie dabei wahrscheinlich zuerst an andere technische Systeme wie Autos, Flugzeuge oder Ihren Computer denken. Ein Computer besteht aus verschiedenen Komponenten. Da gibt es die Grafikkarte, Festplatten, Netzteile, RAM-Module, CPU und so weiter. Jedes Teil hat eine definierte Aufgabe und kann mit anderen Teilen über eine definierte Schnittstelle verbunden werden. Dabei ist die Implementierung nicht weiter von Bedeutung, solange sich die Komponenten an die vereinbarte Schnittstelle halten. So kann beispielsweise ein AMD-Prozessor Typ Ryzen 3700 über die Schnittstelle AM4 auf einem Mainboard mit entsprechendem AM4-Sockel eingesetzt werden. Ebenso ließe sich aber auch ein AMD Ryzen 3500 verwenden; dieser hätte zwar weniger Leistung, sprich eine andere Implementierung, würde den „Vertrag“ der AM4-Schnittstelle aber ebenfalls erfüllen. Jede Komponente könnte genauso gut in einem anderen Rechner mit der entsprechenden Schnittstelle verwendet werden. Über die angebotenen Schnittstellen lassen sich mit entsprechenden Diagnosegeräten Fehler in den angeschlossenen Komponenten aufspüren.Halten wir an dieser Stelle einmal die charakteristischen Eigenschaften einer Komponente in diesem Kontext fest:

• Sie hat genau eine Aufgabe.
• Sie bietet eine Schnittstelle nach
  außen.
• Sie konsumiert die Schnittstellen anderer Komponenten.
• Sie ist wiederverwendbar.
• Sie ist austauschbar.
• Sie lässt sich testen.

Dieses Verständnis einer Komponente ist in der industriellen Fertigung schon seit vielen Jahrzehnten nicht mehr wegzudenken und Teil nahezu jeder modernen Fertigung; und auch die Umgebungen der Fertigung bauen auf diesen Vorteilen auf, beispielsweise die Just-in-time-Lieferketten in der Automobilindustrie.

Können wir das auch?

Das ist genau das, was die Softwareentwicklung erreichen will: einzelne und separierbare Bausteine in einer Anwendung, die wiederverwendbar, austauschbar und testbar sind. Von nun an wird genau diese Überlegung der Motor für die weiteren Artikel zu dieser Artikelreihe zur Architektur der Composite Components 2.0 sein. Software soll sich künftig nur noch aus Komponenten zusammensetzen, die genau diese Eigenschaften besitzen.

Was sind Softwarekomponenten?

Eine Komponente kann theoretisch in der Entwicklung vieles sein: eine Methode, eine Klasse, eine Assembly, eine Schicht, ein Dienst oder eine ganze Anwendung – alle halten die oben erwähnten Eigenschaften einer Komponente ein. Sollten Sie die letzten Episoden von Davids Deep Dive aufmerksam gelesen haben, sollte Ihnen diese Aufzählung bekannt vorkommen. Die vorangegangenen Artikel haben diese immer als Systeme bezeichnet oder als Subsysteme. Und in der Tat: So betrachtet ist eine Komponente nur ein anderer Name für ein System. Aber diese Komponenten sind als „Arbeitselemente“ für eine spezielle Rolle in der Software­entwicklung vorgesehen. Für jede Rolle ist der Begriff der Komponente etwas anderes, bezeichnet aber jeweils eine spezielle Art von System auf seiner Arbeitsebene. Nachfolgend wird das anhand eines Beispiels betrachtet.

Qualitätsaspekte

Die primären Ziele der Komponenten sollen die Wiederverwendbarkeit, die Austauschbarkeit und die Testbarkeit sein. Das alles sind sogenannte Qualitätsaspekte, wie sie beispielsweise im ISO-9126-Qualitätsmodell abgebildet sind [2]. Die Interpretation dieser Qualitätsaspekte ist nun aber stark davon abhängig, in welcher Rolle Sie sich befinden. Stellen Sie sich vor, Sie würden jeweils eine der folgenden Rollen bekleiden:

• Entwickler
• Softwarearchitekt
• Systemarchitekt

Als Entwickler schreiben Sie jeden Tag Quellcode und entwerfen Klassenstrukturen. Wenn ich Sie nun frage, welche Elemente Sie wiederverwenden, austauschen und testen, wird die Antwort wohl „eine Klasse“ sein. Dies ist für Sie das primäre System, um im Softwaredesign genau diese Eigenschaften umzusetzen. Aber Ihr Scope ist nur die Anwendung, in der Sie derzeit entwickeln.Als Softwarearchitekt sind Sie für die Struktur einer oder mehrerer Anwendungen verantwortlich. Wenn ich Sie nun erneut fragen würde, welche Elemente Sie wiederverwenden, austauschen oder testen würden, wäre Ihre Antwort höchstwahrscheinlich „Pakete von Klassen“. Als Software­architekt ist dies das primäre Arbeitselement für die angesprochenen Eigenschaften. Als Architekt verwenden sie keine Klassen, sondern Pakete von Klassen (in .NET: Assemblies). Sie tauschen auch nicht einzelne Klassen aus, sondern ebenfalls Pakete/Assemblies.Als Systemarchitekt sind Sie für die Gesamtintegration aller Anwendungen und Dienste in einem Unternehmen verantwortlich. Hier interessieren Sie sich nicht für Pakete und schon gar nicht für Klassen. Die Elemente, die Sie wiederverwenden oder austauschen möchten, sind Dienste und Anwendungen.So hat also jede Rolle in der Softwareentwicklung einen primären Systemtyp, um diese Eigenschaften umzusetzen:

• Entwickler: Klassen
• Softwarearchitekten: Pakete
• Systemarchitekten: Dienste

Eine Softwarekomponente ist das primäre Arbeitselement in der Softwarearchitektur, und somit ist der Sieger gefunden: Eine Softwarekomponente ist nach obiger Definition ein Paket. Für .NET-Projekte ist es also eine Assembly und für Java wäre es beispielsweise ein JAR-Paket.

Komponentenarchitekturen

Die Maxime in dieser und den nächsten Episoden von Davids Deep Dive wird es sein, maximal gut austauschbare, wiederverwendbare und testbare Softwarekomponenten zu erstellen. Aus diesen Komponenten werden dann, wie in einem ­Lego-Baukasten, ein oder mehrere Softwaresysteme „zusammengesteckt“.Ist in einem Projekt eine Komponente vollständig entwickelt, lässt sie sich in einer Art Werkzeugkasten ablegen, um in späteren Projekten wiederverwendet werden zu können. Das Konzept wird Ihnen sicherlich bekannt vorkommen. Paketmanager wie NuGet oder NPM setzen genau dieses Konzept um, allerdings mit einem anderen Ziel. Solche Paketmanager bieten verschiedenste Bibliotheken für den Einsatz in nahezu jedem Projekt an, beispielsweise Newtonsoft.Json für die Arbeit mit JSON-Dokumenten oder Autofac für die Verwendung von Dependency-Injection-Containern.Unserer Strategie verfolgt ein ähnliches Konzept, allerdings denken wir nicht so „global“ wie bei den genannten Beispielen, sondern denken nur im Rahmen unserer Anwendungen und unseres Unternehmens. Das Ziel wird es sein, aus jeder Komponente im Softwaresystem ein wiederverwendbares, austauschbares und testbares Paket zu machen und daraus die Anwendungen zusammenzusetzen. Eine solche Architektur wird Komponentenarchitektur genannt. Die Composite Component Architecture 2.0, auf die diese Artikelreihe hinarbeitet, repräsentiert eine solche Komponentenarchitektur. In objektorientierten Programmiersprachen ist dies die flexibelste Art von Architekturen, die derzeit erstellt werden können.

Fazit

Ein Entwickler arbeitet täglich mit Klassen und versucht so, seinen Bereich der Arbeit wiederverwendbar, austauschbar und testbar zu machen. Softwarearchitekten müssen sich ein solches „Konstrukt“ selbst erschaffen. Wie diese Episode gezeigt hat, sind dies die Softwarekomponenten. Dies sollte für einen Softwarearchitekten also das primäre Arbeitsmittel sein, um die drei genannten Qualitätsaspekte zu erfüllen. Falls eine Komponentenarchitektur verwendet wird, setzt sich die gesamte Anwendung aus den beteiligten Softwarebausteinen zusammen und baut auf diesen auf.Wer das Thema dieser Episode gerne noch audiovisuell unterfüttern möchte, kann das wie immer mithilfe des dazugehörigen Videos tun [3].Die nächste Episode wird etwas praktischer an die Sache herangehen. Sie wird zeigen, wie Softwarekomponenten am besten „geschnitten“ werden, um ein maximales Maß an Flexibilität zu erreichen. Bis dahin wünsche ich viel Spaß beim Zerteilen Ihrer Anwendung!

Fussnoten

1. Komponente (Software) bei Wikipedia, http://www.dotnetpro.de/SL2007DDD1
2. ISO/IEC 9126 bei Wikipedia, http://www.dotnetpro.de/SL2007DDD2
3. David Tielke, YouTube-Video „Softwarearchitektur mit Komponenten“, http://www.dotnetpro.de/SL2007DDD3