© Shutterstock / 0beron
PHP End to End – Teil 2

Architektur und Struktur


PHP-Applikationen sind häufig Enterprise-Anwendungen, die i. d. R. umfangreich Nutzereingaben entgegennehmen, Daten validieren, diese verarbeiten und in einer Datenbank speichern. Doch welche Struktur erleichtert den Aufbau und führt auch über eine längere Zeit zu einer guten Wartbarkeit? Einige Denkanstöße und ein paar konkrete Lösungsvorschläge werden in diesem Artikel präsentiert.

Steht die Neuentwicklung einer PHP-basierten Webapplikation auf dem Programm, stellt sich auch die Frage nach der richtigen Struktur bzw. Architektur der Anwendung. Bevor wir konkrete Vorschläge mit der Brille des PHP-Entwicklers diskutieren, wollen wir einen übergreifenden Blick auf die Ziele einer Softwarearchitektur richten.

In Analogie zum Bauwesen umfasst der Begriff der „Architektur“ den Bauplan eines Systems im Sinne einer Spezifikation seiner Komponenten und ihrer Beziehungen untereinander [1]. Eine Softwarearchitektur ist also der Bauplan, nach dem das betrachtete Anwendungssystem aufgebaut ist. Dabei kann man unterschiedliche Ebenen (Granularitätsstufen) unterscheiden. Beispielsweise ist eine Differenzierung nach der folgenden Einteilung möglich:

  • Gesamtsystem: Dieses umfasst zum Beispiel die Schichten Systemsoftware (Betriebssystem, Datenbankverwaltungssystem), Middleware (zuständig für die Kommunikation zwischen Softwarekomponenten und für Datenbankzugriffe) und Anwendungssoftware.

  • Grobe Architektur: Hier wird die betrachtete Software funktional in Teilsysteme zerlegt.

  • Feingranulare Architektur: Der Aufbau der Teilsysteme wird festgelegt und beschrieben. Es wird definiert, auf welche Weise die einzelnen Teilsysteme miteinander in Beziehung treten.

Aus der Perspektive des Entwicklungszyklus ist die Softwarearchitektur das Ergebnis des Entwurfs und erfolgt damit in einer frühen Phase des Entwicklungsprozesses. Welche grundsätzlichen Ziele man mit einer „guten“ Softwarearchitektur verfolgt, das ist der Gegenstand des kommenden Kapitels.

Architekturprinzipien

Eine gute und durchdachte Architektur sollte bestimmten Handlungsmustern, sogenannten Architekturprinzipien, folgen. Sie sind allgemeingültig, d. h. man kann sie auf die unterschiedlichsten Arten von Softwaresystemen anwenden. Zu den Prinzipien gehören:

  • Klare Struktur und Abstraktion: Das Ziel einer Softwarearchitektur ist es, die meist hohe Komplexität von umfassenden IT-Systemen zu reduzieren. Damit das gelingt, muss die Architektur eine klare und einfach zu durchschauende Struktur schaffen. Abstraktion besagt, dass man im (meist grafischen) Modell von unnötigen Details während des Entwurfs der Architektur bewusst zu Gunsten der Übersichtlichkeit verzichtet. Ein Beispiel: Beim Entwurf eines Bestellsystems sollte man bereits zu Beginn die einzelnen Programmbestandteile identifizieren, also beispielsweise die Kundenverwaltung, die Artikelverwaltung und das Management der Bestellungen. Der Aufbau der Komponenten im Detail bleibt zunächst im Verborgenen.

  • Konzeptionelle Integrität: Die angewendeten Architekturentscheidungen sollen einheitlich über das gesamte System beibehalten werden. So sollten beispielsweise die Schnittstellen zwischen den Komponenten alle einheitlich aufgebaut sein. Damit wird sichergestellt, dass sich Außenstehende in die Funktionsweise des Systems in akzeptabler Zeit einarbeiten können. Sie können auf diese Weise Muster erkennen und werden nicht bei der Inspektion einer jeden Funktion überrascht. Auch für uns Entwickler ist Einheitlichkeit eine Handlungsmaxime. Nur so haben wir die Chance, dass wir unseren Quellcode und das Gesamtsystem auch noch nach längerer Zeit verstehen. Die Schnittstellen der Kundenverwaltung, der Artikelverwaltung und des Bestellsystems sollten beispielsweise gleich konstruiert sein, d. h., wenn man weiß, wie man einen neuen Kunden hinzufügt, kennt man auch die Logik, wie ein neuer Artikel hinzugefügt werden kann.

  • Modularisierung und Trennung von Zuständigkeiten: Dieses Prinzip besagt, dass jede Komponente der Architektur nur für eine Aufgabe oder einen Aufgabenkomplex verantwortlich ist. Da die Zuständigkeiten klar voneinander abgegrenzt sind, ergibt sich daraus eine modulare Architektur. Natürlich ist auch die Zerlegung des Gesamtsystems in einzelne Module mit Augenmaß zu betreiben, um eine Fragmentierung zu vermeiden. Ein Modul soll zwar grundsätzlich nur eine Aufgabe ausführen, aber diese vollständig. Beispielsweise ist das Teilsystem Kundenverwaltung nur für die Verwaltung der Kunden zuständig. Andere Informationen zum Kunden, wie dessen Bestellungen, werden hier nicht gespeichert, sondern in einem anderen Teilsystem.

  • Bindung und Kopplung: Die Bindung (Cohesion) innerhalb einer Systemkomponente und die Kopplung (Coupling) der Systemkomponenten untereinander bestimmen die Struktur eines Softwaresystems. Die Beziehungen zwischen den Elementen einer Systemkomponente sollen möglichst intensiv, die Kopplung von Softwaresystemen untereinander dagegen möglichst gering sein. Alle Funktionen innerhalb eines Moduls sollen also der Erfüllung einer Aufgabe dienen, unterschiedliche Module sollen unterschiedliche Aufgaben haben. Besteht eine hohe Bindung innerhalb von Komponenten und eine lose Kopplung zwischen ihnen, schafft man die Voraussetzungen für ihre Wiederverwendbarkeit und eine bessere Wartung des Gesamtsystems. Nur so ist es möglich, eine Komponente gegen eine neuere Version mit verbesserter Leistung auszutauschen, ohne dass weitere Änderungen am Gesamtsystem durchgeführt werden müssen. Ebenso können Komponenten eines Systems in einem anderen System ohne Anpassungen wiederverwendet werden. So sind die Teilsysteme Kunden- und Artikelverwaltung unabhängig voneinander und nur über das Bestellmanagement verbunden. Möchte man Änderungen an der Kundenverwaltung durchführ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang