Entstehung

Obwohl das Konzept der Softwarearchitektur so alt ist wie die Softwareentwicklung selbst, gewann der Begriff „Softwarearchitektur“ erst in den späten 1980er Jahren an Bedeutung. Der Credit für die Etablierung dieses Konzepts geht an Computerwissenschaftler wie David Parnas, Mary Shaw und Fred Brooks, die erkannten, dass eine strukturierte Herangehensweise an die Softwareentwicklung notwendig ist, um komplexe Systeme zu verwalten.

Die Forscher bemerkten, dass die steigende Komplexität von Softwareprojekten eine genaue Planung und Organisation erfordert. Damit begann das Zeitalter der Softwarearchitektur, in dem die Gestaltung eines Systems genauso wichtig wurde wie die Implementierung des Codes selbst.

Was ist Softwarearchitektur?

Softwarearchitektur bezeichnet die Struktur eines Softwaresystems, das seine Elemente, die Eigenschaften dieser Elemente und die Beziehungen zwischen ihnen umfasst. Sie bietet einen Plan, der die Arbeitsweise des Systems und die Kommunikation zwischen seinen verschiedenen Teilen definiert. Die Softwarearchitektur legt auch die Regeln und Vorgaben für die Softwareentwicklung und -wartung fest, um sicherzustellen, dass das Endprodukt den Anforderungen entspricht.

Umsetzung

Die Implementierung folgt einer systematischen Methode. Sie beginnt mit der Anforderungsanalyse, in der die funktionalen und nicht-funktionalen Anforderungen des Systems definiert werden. Anschließend wird das Systemdesign erstellt, das die Hauptkomponenten des Systems und ihre Interaktionen definiert. Dieses Design dient als Blaupause für die Entwicklungs- und Wartungsphase.

Es ist wichtig zu beachten, dass die Architektur flexibel genug sein muss, um Änderungen zu ermöglichen, da die Anforderungen oft variieren können. Daher sind iterative Entwicklungsansätze wie Agile (Siehe Agile Manifest) und (DevOps) oft geeignet für die Implementierung der Softwarearchitektur.

Wichtige Punkte bei der Umsetzung der Softwarearchitektur

Die Umsetzung der Softwarearchitektur erfordert sowohl technische als auch organisatorische Kompetenzen. Hier sind einige Punkte, die zu berücksichtigen sind:

• Verständnis der Geschäftsziele: Die Architektur sollte auf den Geschäftszielen und Anforderungen basieren und nicht nur auf technologischen Überlegungen.
• Verwendung von Design Patterns: Design Patterns sind bewährte Lösungen für gemeinsame Designprobleme. Ihre Verwendung kann die Entwicklungszeit verkürzen und die Qualität des Endprodukts verbessern.
• Dokumentation: Eine gut dokumentierte Architektur erleichtert die Kommunikation innerhalb des Entwicklungsteams und die Wartung des Systems. Auch fällt es den Entwicklern durch eine gute Dokumentation leichter, sich in den verschiedenen Komponenten zurechtzufinden.
• Berücksichtigung von Nicht-Funktionalen Anforderungen: Neben den funktionalen Anforderungen sind auch Nicht-Funktionale Anforderungen wie Sicherheit, Leistung und Skalierbarkeit entscheidend. (Siehe in diesem Zusammenhang auch „Nicht funktionale Tests„)

Fazit

Die Softwarearchitektur spielt eine entscheidende Rolle in der Softwareentwicklung. Sie bietet einen strukturierten Ansatz, um komplexe Systeme zu verwalten und zu warten. Durch die Berücksichtigung der oben genannten Punkte können Entwickler eine effektive und effiziente Architektur erstellen, die den Anforderungen gerecht wird und die langfristige Wartung des Systems erleichtert.

Der Beitrag Softwarearchitektur – Entstehung, Bedeutung und Best Practices erschien zuerst auf CEOsBay.

Definition – Strukturelle Tests

Auch bekannt als White-Box-Tests oder Glasbox-Tests, konzentrieren sich auf die interne Perspektive einer Softwareanwendung. Im Gegensatz zu funktionalen Tests, die nur die Anforderungen von Außen prüfen, bieten strukturelle Tests eine vollständige Prüfung der internen Logik und Struktur einer Anwendung.

Notwendigkeit

Es gibt mehrere Vorteile. Sie identifizieren verborgene Fehler, die andere Testmethoden möglicherweise übersehen, erhöhen die Codeabdeckung und verbessern die Qualität der Software. Sie ermöglichen auch eine bessere Identifizierung von Problembereichen, wodurch man effektivere Fehlerbehebungsmaßnahmen einleiten kann.

Durchführung von strukturellen Tests

Strukturelle Tests erfordern ein gründliches Verständnis der internen Softwarearchitektur. Dies schließt Wissen über Datenflüsse, Kontrollstrukturen, Schnittstellen und weitere Details ein. Tester führen eine detaillierte Analyse der Codebasis durch, um Schwachstellen und mögliche Fehlerquellen zu identifizieren. Anschließend erstellt man geeignete Testfälle und führt diese aus, um die Funktionsweise der Anwendung zu überprüfen.

Typen – Strukturelle Tests

Verschiedene Typen struktureller Tests richten sich an spezifische Bereiche der Codebasis. Einige der gängigen Arten sind Kontrollflusstests, Datenflusstests, Pfadtests und Schleifentests. Jeder dieser Tests konzentriert sich auf ein bestimmtes Aspekt des Codes und liefert wichtige Informationen über dessen Leistung und Zuverlässigkeit.

Fazit

Zusammenfassend lässt sich sagen, dass strukturelle Tests ein effektives Mittel sind, um die Qualität und Zuverlässigkeit von Softwareanwendungen zu gewährleisten. Durch eine detaillierte Überprüfung der internen Struktur einer Anwendung tragen sie dazu bei, verborgene Fehler zu identifizieren und sicherzustellen, dass alle Komponenten korrekt funktionieren. Mit ihrer Hilfe kann das Vertrauen in die entwickelte Software erhöht und das Risiko von Fehlern reduziert werden. Es lohnt sich also, in diese Tests zu investieren und sie als festen Bestandteil des Softwaretestprozesses zu etablieren.

Der Beitrag Strukturelle Tests in der Softwareentwicklung erschien zuerst auf CEOsBay.

Die Wurzeln des Pestizid-Paradoxons liegen in der Landwirtschaft. Wenn ein Bauer ständig dasselbe Pestizid verwendet, um seine Ernte zu schützen, entwickeln schließlich die Schädlinge, die überleben, eine Immunität gegen dieses spezifische Pestizid. Im Laufe der Zeit verliert das Pestizid seine Wirksamkeit. Analog dazu, in der Softwareentwicklung, wenn Entwickler und Tester immer wieder dieselben Tests anwenden, werden sie nur die Fehler finden und beheben, die diese Tests identifizieren können.

Das Pestizid-Paradoxon in der Softwareentwicklung verweist also auf die Notwendigkeit, kontinuierlich neue und verschiedene Testfälle zu erstellen. In der modernen agilen Entwicklung (Siehe Beitrag „Agiles Manifest„), bei der man Software kontinuierlich ändert und verbessert, muss das Testen Schritt halten und sich anpassen.

Mit der Zeit entdecken Testfälle weniger und weniger Bugs, genau wie Pestizide, die ihre Wirksamkeit gegen Schädlinge verlieren. Um Qualität und Sicherheit zu gewährleisten, muss man die Testszenarien daher regelmäßig überprüfen und aktualisieren. Ebenso muss man neue Tests entwickeln, um auf veränderte oder neue Funktionen zu reagieren.

Ein weiterer zentraler Aspekt des Pestizid-Paradoxons in der Softwareentwicklung ist die Notwendigkeit einer vielfältigen Teststrategie. Dazu gehören Funktionstests, Integrationstests, Leistungstests, Sicherheitstests und Benutzerakzeptanztests. Ein vielfältiges Test-Portfolio, das verschiedene Aspekte und Ebenen der Software abdeckt, erhöht die Wahrscheinlichkeit, dass mehr Fehler entdeckt und behoben werden.

Das Pestizid-Paradoxon ist somit eine starke Erinnerung daran, dass Veränderung in der Softwareentwicklung nicht nur unausweichlich, sondern notwendig ist. Es lehrt uns, dass wir uns nicht auf bewährte Testverfahren verlassen sollten. Es macht Sinn, ständig neue Methoden und Ansätze zu entwickeln und anzuwenden, um Softwarequalität und -sicherheit zu gewährleisten.

Der Beitrag Pestizid-Paradoxon – Resistenz von Bugs und Fehlern erschien zuerst auf CEOsBay.

1. Testen zeigt die Anwesenheit von Fehlern

Das Hauptziel des Testens ist es, Fehler und Mängel in einem System zu identifizieren. Es ist jedoch wichtig zu bedenken, dass das Testen nicht beweisen kann, dass ein System absolut fehlerfrei ist. Das Ausbleiben entdeckter Fehler bedeutet nicht zwangsläufig, dass das System perfekt ist.

2. Vollständiges Testen ist nicht möglich

Es ist unpraktisch und oft unmöglich, alle Kombinationen von Eingaben, Szenarien und Ausführungspfaden in einem komplexen System zu testen. Daher ist eine Teststrategie erforderlich, die auf Risikobewertung und Priorisierung basiert.

3. Grundsatz: Frühzeitiges Testen

Die Minimierung der Kosten und des Zeitaufwands für die Fehlerbehebung erfordert den Beginn der Testaktivitäten so früh wie möglich im Entwicklungszyklus. Der „Shift-Left“-Ansatz im Testen unterstreicht dieses Prinzip.

4. Grundsatz: Häufung von Fehlerzuständen

Das Pareto-Prinzip, auch bekannt als 80/20-Regel, ist auch im Testen relevant: 80% der Fehler treten normalerweise in 20% der Module auf. Dies unterstreicht die Bedeutung einer gezielten Testplanung.

5. Pestizid-Paradoxon bzw. Pestizid-Resistenz

Wiederholtes Durchführen derselben Tests führt schließlich zu einer Abnahme ihrer Effektivität bei der Identifizierung neuer Fehler. Daher ist es wichtig, Tests regelmäßig zu überprüfen und zu aktualisieren, um ihre Effektivität zu erhalten. (Siehe auch meinen Beitrag Pestizid-Paradoxon – Resistenz von Bugs und Fehlern)

6. Grundsatz: Testen ist kontextabhängig

Die Art und Weise, wie getestet wird, hängt stark vom Kontext ab, in dem das System eingesetzt wird. Ein Finanzsystem erfordert beispielsweise strengere Testanforderungen als ein persönliches Blogging-Tool wie WordPress.

7. Grundsatz: Fehlerabsenz-Trugschluss – Keine Fehler bedeutet ein brauchbares System

Das erfolgreiche Durchlaufen von Tests ist nicht gleichbedeutend mit der Einsatzbereitschaft des Systems. Eine sorgfältige Bewertung der Testergebnisse und der Qualität des Systems insgesamt ist unerlässlich, bevor eine Bereitstellungsentscheidung getroffen wird.

Fazit

Indem diese Grundprinzipien beachtet und in die Teststrategie integriert werden, kann man die Qualität von Systemen sicherstellen. Vor allem lassen sich die Systeme dadurch effektiv bewerten und kontinuierlich verbessern.

Ein spezifisches Manifest, das ausschließlich die Grundprinzipien des Testens behandelt, ähnlich wie das Agile Manifest, die Werte und Prinzipien agiler Softwareentwicklung definiert, existiert nicht. Die genannten Grundprinzipien sind jedoch weitgehend anerkannt und in zahlreichen Standards, Best Practices und Schulungsmaterialien für das Testen von Software und Systemen festgelegt.

Einer der am häufigsten referenzierten Standards ist das ISTQB (International Software Testing Qualifications Board), das ein detailliertes „Body of Knowledge“ für das Softwaretesten bietet und dabei viele dieser Grundprinzipien behandelt. Dazu werde ich bestimmt in naher Zukunft auch noch einen Beitrag schreiben.

Außerdem gibt es Manifeste und Prinzipien, die sich mit Qualitätssicherung und Testen im Kontext spezifischer Ansätze wie Agile oder DevOps befassen. Diese Manifeste betonen oft Aspekte wie kontinuierliches Testen, die Einbeziehung von Testen in alle Phasen des Entwicklungslebenszyklus und die Bedeutung von Automatisierung beim Testen.

Der Beitrag Die Sieben Grundprinzipien des Testens – Eine Übersicht erschien zuerst auf CEOsBay.

Was ist Swagger?

Swagger, auch bekannt als OpenAPI, ist ein Open-Source–Framework zur API-Entwicklung. Es bietet Entwicklern eine standardisierte Methode, um RESTful-APIs zu entwerfen, zu dokumentieren und zu testen. Es hilft Entwicklern dabei, die Kommunikation zwischen verschiedenen Anwendungen zu vereinfachen und fördert die Zusammenarbeit innerhalb und zwischen Teams.

Die wichtigsten Komponenten:

1. Swagger Editor: Ein browserbasiertes Werkzeug zur Erstellung und Bearbeitung von OpenAPI-Spezifikationen.
2. Swagger UI: Eine benutzerfreundliche Oberfläche, die es Entwicklern und Endbenutzern ermöglicht, API-Dokumentationen interaktiv zu visualisieren und zu testen.
3. Swagger Codegen: Ein Generator, der serverseitigen und clientseitigen Code für APIs auf Basis der OpenAPI-Spezifikation erstellt.

Vorteile

1. Klare und präzise API-Dokumentation: Es ermöglicht Entwicklern, leicht verständliche und konsistente API-Dokumentationen zu erstellen. Dadurch wird die Kommunikation zwischen Teammitgliedern und die Integration von APIs in verschiedene Systeme erleichtert.
2. Zeitersparnis: Die automatische Generierung von serverseitigem und clientseitigem Code reduziert die manuelle Arbeit und beschleunigt die Entwicklung von APIs.
3. Fördert die Zusammenarbeit: Es erleichtert die Zusammenarbeit zwischen Frontend- und Backend-Entwicklern, indem es eine gemeinsame Sprache und Struktur bietet.
4. Einfache Aktualisierung und Pflege: Man kann Änderungen an einer API problemlos in die bestehende Dokumentation integrieren, ohne dass man die gesamte Dokumentation manuell aktualisieren muss.
5. Benutzerfreundlichkeit: Die visuelle Darstellung der API-Endpunkte durch Swagger UI erleichtert das Verständnis der API-Funktionalität und ermöglicht das Testen direkt aus der Dokumentation heraus.

Fazit

Swagger, im Programmierkontext, hat sich als unverzichtbares Werkzeug für Entwicklerteams etabliert, um effizient und effektiv RESTful-APIs zu entwickeln und zu verwalten. Mit seinen leistungsstarken Funktionen zur Gestaltung, Dokumentation und Zusammenarbeit trägt Swagger wesentlich zur Steigerung der Produktivität und Qualität von Softwareprojekten bei. Es ist nicht nur ein nützliches Tool, sondern auch ein Beispiel dafür, wie offene Standards und innovative Technologien die IT-Landschaft nachhaltig beeinflussen können.

Der Beitrag Swagger – Mühelose API-Dokumentation und Interaktion für effiziente Entwicklungsprozesse erschien zuerst auf CEOsBay.

Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen erschien zuerst auf CEOsBay.