Softwareentwickler und -entwicklerinnen verwenden manchmal Wörter, ohne dass ihnen die Bedeutung klar ist. Beispiele gefällig? Was ist ein Modul? Oder eine Komponente? Bei Methode und Klasse werden wir uns sicher schnell einig. Aber einige Begriffe erfordern eine Definition. Wir haben daher eine Modulhierarchiedefiniert, in der die „Behälter für Logik“ untergebracht sind.
Beginnen wir mit einer Auflistung der Begriffe, um die es im Folgenden gehen wird:
- Methode (method)
- Klasse (class)
- Bibliothek (library)
- Paket (packet)
- Komponente (component)
- Microservice (microservice)
Die Abbildung zeigt die Hierarchie der Module. Modul ist hier der Überbegriff, sprich eine Komponente ist ein Modul, genauso wie ein Paket, etc. Die Abbildung zeigt, wie wir von unten nach oben Module zu immer größeren Einheiten zusammenfassen können. Methoden werden zusammengefasst zu Klassen, diese werden zusammengefasst zu Bibliotheken usw.
Methoden und Klassen (Dateien)
Auf der untersten Ebene haben wir Methoden und Klassen als Module, die Logik in textueller Form aufnehmen. In allen Sprachen müssen Methoden in Dateien abgelegt werden. Dies gilt auch für solche, in denen keine Klassen zur Verfügung stehen oder nicht zwingend erforderlich sind. Insofern kann der Begriff Klasse synonym verstanden werden zu Datei.
Wir könnten den Begriff Methode nun präzise definieren. Ich vermute jedoch, dass unsere Vorstellungen darüber, was eine Methode ist, sehr ähnlich sind. Insofern erspare ich uns eine formale Definition.
Bibliotheken
Klassen bzw. Dateien können zu Bibliotheken zusammengefasst werden. In .NET sind dies DLLs, in Java JAR Files, in C++ .lib oder .a Dateien usw. Der wichtigste Unterschied zu den Ebenen darunter: ab dieser Ebene liegt die Logik nur noch binär vor, nicht mehr textuell. Selbst in interpretierten Sprachen wie Python oder JavaScript, in denen technisch gesehen der Quellcode vorliegen mag, sehen wir diesen als Verwender nicht. Wie eine Bibliothek technisch im Dateisystem abgelegt ist, ist für den Verwender transparent. Insofern kann man auch bei den interpretierten Sprachen von einer quasi-binären Repräsentation sprechen. Bibliotheken dienen dem Deployment.
Paket
Fügen wir zu einer Bibliothek Metadaten und eine Versionierung hinzu, entsteht ein Paket. Gemeint ist hier nicht die Versionskontrolle wie git, sondern eine Infrastruktur, die es uns erlaubt, Pakete unterschiedlicher Versionen aufzunehmen. Ferner ist zu jedem Paket hinterlegt, von welchen anderen Paketen dieses abhängig ist. Auch dabei sind Versionsnummern hinterlegt, so dass beim Hinzufügen eines Paketes zu einem Projekt die benötigten Abhängigkeiten ebenfalls bereitgestellt werden können. Beispiele für Pakettechnologien sind NuGet, Maven, npm, pip und andere.
Würde man versuchen, Logik auf der Basis von Bibliotheken wiederzuverwenden, wäre es sehr schwer zu erkennen, ob eine neue Version vorliegt. Ferner müssen beim direkten Einsatz von Bibliotheken die Abhängigkeiten selbst bereitgestellt werden. Pakete dienen daher vor allem der Wiederverwendung.
Komponente
Für die arbeitsteilige Implementation sind Kontrakte erforderlich. Bevor arbeitsteilig implementiert werden kann, muss durch die Kontrakte geklärt werden, wie die einzelnen Bestandteile später zusammengefügt, also integriert, werden. Die Kontrakte definieren das Zusammenwirken der Teile und dienen der Abgrenzung. Für die Kontrakte werden technisch gesehen Interfaces und Datentypen verwendet. Diese Kontrakte müssen bereits existieren, bevor gegen sie implementiert werden kann. Folglich müssen sie separat von der Implementation abgelegt werden. Somit besteht eine Komponente aus mindestens zwei Paketen: eines enthält die Kontrakte, das oder die anderen die Implementation.
Bei den Kontrakten können wir zunächst unterscheiden zwischen impliziten und expliziten Kontrakten. Jede Methode und Klasse hat einen impliziten Kontrakt. Bei Methoden ist dies die Signatur. So kann bspw. eine Methode über ihren impliziten Kontrakt aufgerufen werden, wenn der Name korrekt verwendet wird und die Konventionen für die Parameter eingehalten werden.
Explizit wird ein Kontrakt dadurch, dass ein Interface definiert wird. Die Methode oder Klasse muss diesen expliziten Kontrakt implementieren und kann dann über den Kontrakt aufgerufen werden. Für Methoden ist ein expliziter Kontrakt bspw. eine delegate Definition in .NET. Erwartet eine Methode ein Objekt vom Typ Action<string>, kann diese Methode über diesen expliziten Kontrakt aufgerufen werden. Zur Laufzeit können alle Methoden eingesetzt werden, die sich an diesen expliziten Kontrakt halten.
Für Klassen ist das Interface der explizite Kontrakt.
Separiert man den Kontrakt in ein eigenständiges Paket von der Implementation, spricht man von einem separaten Kontrakt. Komponenten sind somit binäre Module mit separatem Kontrakt. Komponenten dienen der arbeitsteiligen Implementation.
Microservice
Die oberste Ebene der Modulhierarchie bilden die Microservices. Sie unterscheiden sich von Komponenten dadurch, dass sie über einen plattformneutralen Kontrakt verfügen. Dieser kann bspw. als http/REST Schnittstelle definiert werden. Somit ist es dann egal, mit welcher Plattform ein Microservice implementiert wird. Ein Java Microservice kann einen .NET Microservice aufrufen, sofern er sich an den plattformneutralen Kontrakt hält.
Microservices dienen dem Deployment.
Fazit
Ein Begriff ist ein Wort mit Bedeutung. Wenn Softwareentwickler sich unterhalten und bspw. unterschiedliche Lösungsmöglichkeiten diskutieren, sollten dabei unbedingt Begriffe verwendet werden statt leerer Worte. Nur wenn jedem im Team klar ist, was bspw. mit dem Wort Paket gemeint ist, kann ein sinnvolles Gespräch stattfinden. Das Wort Paket wird dann zum Begriff, unter dem jeder das gleiche versteht. Haben zwei Entwickler eine unterschiedliche Bedeutung des Wortes Komponente im Hinterkopf, werden sich die mentalen Modelle in den Köpfen dieser Entwickler unterscheiden und Missverständnisse sind vorprogrammiert.
Leider sind die hier aufgeführten Begriffe nicht einheitlich in der Informatik definiert. Hier ist dargestellt, wie wir die dargestellten Begriffe in der CCD Akademie verwenden. Sei also darauf vorbereitet, dass andere Entwickler oder Autoren manche Begriffe anders verwenden. Speziell bei Komponente und Modul ist die Gefahr groß, dass eine andere Bedeutung gemeint ist. Im Zweifel: nachfragen und klären.
German 
English
1 Kommentar zu „Die Modulhierarchie“
Pingback: Softwarearchitektur: Verantwortlichkeiten und Abhängigkeiten - CCD Akademie GmbH