Softwarearchitektur: Systeme nach Ihrem Bedarf

Warum sollte man sich mit Softwarearchitektur beschäftigen?

Stellen Sie sich ein Szenario vor, in dem Sie und ein kleines Team an einer einfachen E-Commerce-Anwendung arbeiten, ohne sich über Softwarearchitektur Gedanken zu machen. Zu Beginn werden Sie mit nur wenigen Benutzern vielleicht keine Probleme haben, und das Hinzufügen neuer Funktionen kann schnell und ohne viel Aufhebens erledigt werden. Wird Ihre Anwendung allerdings von mehr und mehr Nutzern angesprochen, kann dies wegen zu hoher Last zu Abstürzen führen, da Skalierungsaspekte nicht von Anfang an berücksichtigt wurden. Im Laufe der Zeit können neue Funktionen die Situation sogar noch verschlimmern, wenn diese z.B. verschiedene, zusätzliche Betriebsmittel erfordern, die in den unterschiedlichsten Anwendungsfällen knapp werden können. Daher kann jede neue Funktion der Grund für Abstürze auf unterschiedlichen Ausführungspfaden sein und die Suche und Umsetzung von Behelfslösungen kann Ihren Code in ein historisch-gewachsenes Durcheinander verwandeln, mit aufgeschobenen technischen Schulden und ohne Optionen für einen tieferen Einblick. Infolgedessen dauert die Behebung von Fehlern jedes Mal länger, und Sie haben Schwierigkeiten, das System am Laufen zu halten. Die Folge, ihre Benutzer fangen an, sich über unzureichende Leistung und Abstürze zu beschweren.

Schließlich sehen Sie keine andere Lösung mehr, als in eine moderne Cloud-Umgebung umzuziehen, um zusätzliche Betriebsmittel schnell bereitstellen und nutzen zu können. Doch dann stellen Sie fest, dass Ihre Anwendung bereits zu einem zu großen und komplexen “Code-Schlamassel” angewachsen ist, der eine komplette Neufassung erfordert. Diese umzusetzen kostet Sie viele Monate und eine beträchtliche Summe Geld und möglicherweise sogar einen großen Teil Ihrer inzwischen unzufriedenen Kunden. Und nun müssen Sie das tun, was Sie von Anfang an hätten tun sollen, um diese traurige Geschichte zu vermeiden: sich um Ihre Softwarearchitektur kümmern.

Was ist Softwarearchitektur?

Im weitesten Sinne ist Softwarearchitektur eine detaillierte Abstraktion eines Softwaresystems. Sie beschreibt, was das System tut und wie es funktioniert, aber sie gibt auch Aufschluss darüber, wie gut das Softwaresystem seine Aufgabe erfüllt. Konkret befasst sich die Softwarearchitektur mit den beiden Hauptanliegen beim Aufbau eines Softwaresystems. Erstens, die Berücksichtigung aller funktionalen Anforderungen an das System. Diese werden durch Softwarekomponenten beschrieben, die die Struktur des Systems bilden. Dabei wird das Verhalten und die Interaktion zwischen den Komponenten durch Daten- und Arbeitsabläufe definiert. Zweitens, Softwarearchitektur muss innerhalb vorgegebener Hardware- und Technologiebeschränkungen alle nicht-funktionalen Anforderungen berücksichtigen. Diese dienen dazu eine gute Performanz des Systems, entsprechend vordefinierten Qualitätsparametern zu gewährleisten. Lassen Sie uns im Folgenden diese Begriffe näher erläutern.

Funktionale Anforderungen

Die funktionalen Anforderungen stellen die Geschäftslogik, die Funktionalität und die Eigenschaften der Software dar. Sie geben genau an, was eine Softwareanwendung oder ein System tun soll.

Softwarekomponenten

Die Softwarekomponenten sind die einzelnen Funktionsbausteine, die einzelnen Einheiten oder Module, die zusammen ein Softwaresystem bilden. Jede Komponente ist für einen bestimmten Teil der Gesamtfunktionalität verantwortlich. Dabei kann es sich um einen Dienst, eine Nachrichtenwarteschlange oder eine beliebige Art von Datenspeicher handeln, z. B. eine Datenbank. Je nach gewählter Architektur (auf verschiedene Softwarearchitekturen wird später in diesem Artikel eingegangen) kann es sich aber auch um eine Schicht oder ein Modul innerhalb eines einzigen großen, in sich geschlossenen Dienstes handeln.

Softwarekomponenten sind kohärente Bausteine des Systems, die einzeln verwaltet, getestet und im Idealfall auch betrieben werden können.

Daten- und Arbeitsablauf

Software-Komponenten können miteinander entweder synchron kommunizieren, d.h. über direkte Anwendungsschnittstellen, oder asynchron, indem sie aktiv Nachrichten anfordern oder passiv Nachrichten erhalten, sobald diese verfügbar sind. Beispiele für eine asynchrone Kommunikation sind der Nachrichtenaustausch über Nachrichten-Broker, mittels Ereignisbenachrichtigungen oder gar das Teilen von Statusinformationen über eine Datenbank. All diesen Kommunikationsmethoden ist gemein, dass sie darauf abzielen, benötigte Daten oder Arbeitsanweisungen von einer Komponente zur anderen zu übertragen. Die Daten- und Arbeitsabläufe beschreiben hierbei, wie und was kommuniziert wird. Das allgemeine Ziel ist stets, dass Komponenten zusammenarbeiten, um eine größere, übergeordnete Funktion zu erfüllen. Die Art der Kommunikation hängt insofern vom zu lösenden Problem und seiner nicht-funktionalen Anforderungen ab. Unabhängig davon, ob die Kommunikation in Echtzeit oder verzögert erfolgt, gewährleisten die Daten- und Arbeitsabläufe zwischen den Komponenten, die Korrektheit, Integrität und Zuverlässigkeit der übergeordneten Funktion. Mittels unterschiedlicher Kommunikationsarten können verschiedene Kommunikationsengpässe umgangen werden, z. B. durch Verbesserung der Skalierbarkeit und des Durchsatzes.

Nicht-funktionale Anforderungen

Ein wichtiger Aspekt der Softwarearchitektur ist die Erfüllung der nicht-funktionalen Anforderungen an ein System. Nicht-funktionale Anforderungen sind Qualitäts- und Leistungsmerkmale, die ein Softwaresystem erfüllen muss. Sie betreffen in der Regel die Ausführungszeiten, die Zuverlässigkeit oder die Sicherheit des Systems. Nicht-funktionale Anforderungen sind wichtig, um festzustellen, ob ein System in allen Anwendungsfällen gut funktioniert.

Beispiele für nicht-funktionale Anforderungen sind Anforderungen an:

• Leistung, um sicherzustellen, dass das System eine bestimmte Last bewältigen kann, z. B. in Bezug auf den Durchsatz oder einzelne Antwortzeiten
• Skalierbarkeit, um sicherzustellen, dass das System leicht an eine sich verändernde Last angepasst werden kann
  Verfügbarkeit, um sicherzustellen, dass das System innerhalb bestimmter Grenzen immer betriebsbereit ist
• Zuverlässigkeit, um sicherzustellen, dass das System innerhalb bestimmter Garantien korrekt funktioniert, Fehler zuverlässig behandelt, usw.
• Sicherheit, um die Sicherheit und Integrität von Daten und System zu gewährleisten

Hardware- und Technologiebeschränkungen

Ein weiterer, nicht zu unterschätzender Aspekt beim Entwurf einer Softwarearchitektur sind die Hardware- und Technologiebeschränkungen, die dem Softwaresystem auferlegt sind.

Die Hardware-Beschränkungen müssen mit den nicht-funktionalen Anforderungen berücksichtigt werden. Es muss sichergestellt werden, dass die vorhandene oder geplante Infrastruktur ausreicht und keine Kostenexplosion verursacht wird, falls zusätzliche Hardware angeschafft werden muss. Ein Schlüsselaspekt betrifft die Effizienz der Softwarekomponenten. Es muss gewährleistet werden, dass die verfügbaren Hardware-Betriebsmitteln für alle Komponenten ausreichen, z. B. hinsichtlich Anzahl Prozessoren, Arbeitsspeichergröße, Datenspeichertyp und -kapazität, sowie Kommunikationsaufwand und Netzwerkgeschwindigkeit.

Die technologischen Beschränkungen beziehen sich auf Software-Abhängigkeiten. Möglicherweise müssen bestimmte Frameworks, Anwendungen oder Technologien für eine Anwendung verwendet werden, während andere nicht verwendet werden dürfen. Beispielsweise können Daten, mit denen Ihre Software umgehen soll, in einer vorgegebenen relationalen Datenbank gespeichert sein, oder es müssen Lizenzgebühren vermieden werden, wodurch bestimmte Technologien ausgeschlossen sein können. Es könnte im Gegenteil auch verpflichtend sein, eine bestimmte Bibliothek, ein bestimmtes Kommunikationsprotokoll oder ein Web-Framework zu verwendet, z.B. aufgrund einer Partnerschaft mit einem Softwareanbieter.

Solche Hardware- und Technologiebeschränkungen erhöhen zusätzlich die Komplexität Ihrer Softwarearchitektur. Ihre Betrachtung ist aber unvermeidlich, um eine bestmögliche Lösung zu finden.

Erfahren Sie mehr über typische Softwarearchitekturmuster in Teil 2 dieser Blog-Post-Serie zu Softwarearchitekturen.

Autor © 2024: Dr. Tom Crecelius – www.linkedin.com/in/tom-crecelius-65a16949/