Das Dokument behandelt die Softwarearchitektur und die Aufgaben von Softwarearchitekten sowie die Zusammenarbeit zwischen Softwarearchitekten und -entwicklern. Es erklärt die Bedeutung der Architektur in Bezug auf funktionale und nicht-funktionale Anforderungen und die Einflüsse von Conway's Law auf die Struktur und Kommunikation innerhalb von Organisationen. Zudem werden Methoden zur Architektur-Dokumentation und Kommunikation im Projektverlauf sowie Herausforderungen bei der Planung und Anpassung an emergente Anforderungen diskutiert.

1. Softwarequalität
Architektur & Qualität
Prof. Dr. Wolfgang Golubski Gerrit Beine, M.Sc.
golubski@fh-zwickau.de mail@gerritbeine.com
1

2. Aufgaben von Software-Architektur
2

3. Aufgaben der Software-Architektur
● Software-Architektur:
Beschreibt die Komponenten einer Software sowie deren funktionales Zusammenspiel.
● SWEBOK (Software Engineering Body of Knowledge, IEEE) ordnet Software-Architektur zur
der Entwurfsphase zu
● Software-Architektur ist die Summe von Design-Entscheidung vor der Implementierung
● Praktisch ist die Software-Architektur der IT-Architektur und der
Unternehmensarchitektur untergeordnet
● IT-Architektur: Infrastruktur (Hard- und Software) im Unternehmen
● Unternehmensarchitektur: Zusammenspiel der IT-Elemente im Sinne des
geschäftlichen Zwecks
● Software-Architektur verantwortet im Wesentlich Nicht-Funktionale Anforderung
● FURPS (Functionality, Usability, Reliability, Performance, Supportability)
siehe auch ISO 9126
3

4. Kollaborative Aufgaben des Software-Architekten
● Requirements Engineering
● Festlegen von Nicht-Funktionalen Anforderungen
● Bewerten von funktionalen Anforderungen hinsichtlich ihrer Bedeutung für die
Architektur
● Betriebsführung
● Definition der Laufzeitumgebung, Hardware, Betriebssystem, Datenbank
● Festlegung des Deployments, Verteilung von Client-Anwendungen
● Test
● Design for Testability während Design und Implementierung
● Unterstützung des Testmanagements in allen Phasen
● Projektmanagement
● Tracking der Nicht-Funktionalen Anforderungen
● Auswahl und Definition einer Architektur mit Blick auf Zeit und Kosten
4

5. Software-Architekten & Software-Entwickler
● Software-Architekten machen Vorgaben für Projekte
● Überblick des Gesamtprojektes, Kontext-bezogenes Wissen
● Software-Entwickler realisieren konkrete Lösungen für Teilaspekte des Projektes
● Tiefes Detailwissen bezüglich Frameworks und Problemstellungen
● Software-Architekten sollten:
● Erklären, WARUM sie welche Vorgabe machen
● Kontext-Wissen transparent machen, Überblick ermöglichen
● Programmieren können; Code-Beispiele sind gute Eisbrecher
● Zuhören
● Software-Entwickler sollten:
● Fragen, warum etwas vorgegeben wurde
● Begründen, warum abgewichen werden sollte
5

6. Architektur, Conway's Law und das Problem der
Komponententeams
6

7. Conway's Law
“… organizations which design systems … are constrained to produce designs which are copies
of the communication structures of these organizations”
Melvin Conway, 1968
● Bedeutung für die Software-Architektur
● Die fachliche Architektur einer Anwendung sollte immer der Struktur des
Fachbereichs folgen, der die Anwendung nutzen wird.
● Die technische Architektur sollte immer die fachlichen Architektur widerspiegeln und
sie erweitern.
● Build-Strukturen sollten immer der technischen Architektur folgen.
● Bei der Planung von Software und dem Team-Setup eines Projektes sollte Conway's Law
berücksichtigt werden.
7

8. Conway's Law und Modellebenen
Sicht Artefakte Beziehungen
Geschäftsobjektsicht Business Objects, repräsentiert Ausschließlich zwischen
durch Klassen, sehr hohes Business Objects
Abstraktionsniveau
Anforderungssicht Requirements, Functional & Verbindung zwischen Functional
Non-Functional & Non-Functional Requirements,
Abhängigkeiten zu Business
Objects
Anwendungsfallsicht Use Cases, Actors Use Cases realisieren
Manchmal hier sinnvoll: Requirements
Fachklassenmodelle Use Cases benötigen Business
Objects (oder Fachklassen)
Fachliche Architektur Components, Dependencies, Component realisiert Use Case
Fachlich orientiert, Keine
technologische Aspekte
Technische Architektur Components, Dependencies, Component realisiert
Technische Aspekte sichtbar, Component aus Fachlicher
Grundlage für Build Process Architektur
8

9. Komponenten und Subsysteme
● Komponente:
● "A software component is a unit of composition with contractually specified
interfaces and explicit context dependencies only. A software component can be
deployed independently and is subject to composition by third parties."
(Clemens Szyperski, Component Software, ACM Press/Addison-Wesley, England, 1998)
● "Eine Software-Komponente ist ein Software-Element, das konform zu einem
Komponentenmodell ist und gemäß einem Composition-Standard ohne Änderungen
mit anderen Komponenten verknüpft und ausgeführt werden kann."
(William T. Councill, George T. Heineman: Component-Based Software Engineering. Addison-Wesley, 2001, ISBN 0-201-70485-4)
● Subsystem:
● Ein Subsystem (Teilsystem) ist eine Komponente, die sehr groß ist oder sich aus
mehreren Komponenten zusammensetzt.
● Agiles Identifizieren von Subsystem: Ein Subsystem besteht aus einer oder mehreren
Komponenten, die für sich stehend einen Geschäftswert erzeugen.
9

10. Komponententeams und Featureteams
● Komponententeams haben in der Regel eine hohe Domänenkompetenz tendieren aber
zur Wasserfall-Entwicklung.
● Feature-Teams sind in der Regel Cross-Funktional, haben kaum Übergabepunkte und
tendieren eher zu agilen und emergenten Entwicklungen.
● Wann lohnen sich Komponententeams?
● In großen Wartungsprojekten, wenn Änderungen kontinuierlich erfolgen.
● Wann lohnen sich Featureteams?
● In Greenfield-Projekten
● In Brownfield-Projekten, wenn ein schlechter Komponentenschnitt vorliegt oder nicht
kontinuierlich an einzelnen Komponenten weiterentwickelt wird.
● Das Problem mit dem Collaborative-Code-Ownership:
● Idealerweise sollte nur ein Feature-Team zu einem Zeitpunkt ein Teilsystem
bearbeiten, klappt das nicht, sollte pro Komponente nur ein Team arbeiten.
● In großen Projekten sollte ein Feature-Team für die betroffenen Komponenten
verantwortlich sein, bis das Feature implementiert ist.
10

11. Architektur-Dokumentation
11

12. Die vier Sichten von Architekturdokumentation
● Kontextabgrenzung
Einbettung in der Umgebung, Kontextabgrenzung
Schnittstellen zu Nachbarsystemen,
System ist Blackbox
● Bausteinsicht
Interne Sicht des Systems, statische Laufzeitsichten
Strukturen, Abhängigkeiten zwischen
Komponenten
● Laufzeitsicht
Interne Sicht, Verhaltensbeschreibungen,
Interaktion der Bausteine zur Laufzeit, Bausteinsichten
Beschreibung des dynamischen
Strukturen
● Verteilungssicht
Externe Sicht, Topologie des Systems, Verteilungssichten
Infrastruktur, Hardware, Deployment
Vier Arten von Sichten
(Nach „Effektive Software-Architekturen“, Gernot Starke, 4. Auflage, 2009,
Carl Hanser Verlag München)
12

13. Schnittstellendokumentation
● Schnittstellen zu externen Systemen müssen dokumentiert sein
● Formal mit Beschreibungssprachen wie WSDL, WADL, Corba-IDL oder API-Dokumentation
● Elemente der Schnittstellendokumentation
● Versionsinformationen der Schnittstelle
● Bereitgestellte Ressourcen (API-Dokumentation)
● Semantik der Ressourcen (Events, Daten, Zustände) sowie potentieller Änderungen
● Restriktionen hinsichtlich der Benutzung der Schnittstelle
● Fehlerszenarien, Konfigurationsparameter
● Erklärung der Entwurfsentscheidungen
● Verfügbarkeit der Schnittstellen (sowohl operativ als auch strategisch)
● Reaktionszeiten bei Problemen
● Ansprechpartner beider beteiligten Systeme
● Beispiele zur Verwendung
13

14. Architektur-Dokumentation
● Inhalte
● Strukturen des Systems (Vier Sichten)
● Schnittstellen, idealerweise als Kontrakte mit Ansprechpartnern
● Architektur-Entscheidungen mit ihren Begründungen
● Umfang von Architektur-Dokumentation
● So wenig wie möglich, so viel wie nötig
● Weniger ist oft mehr, lange Prosa-Dokumente schrecken oft ab
● Bilder sagen mehr als Worte, Zusammenhänge lassen sich visuell gut transportieren
● Verständlichkeit ist zwingend, Sprachen wie UML sind optional
● Gut geeignet ist Architekturtapete
● Einzelne Aspekte der Architektur werden auf Packpapier an der Wand verewigt
● Erklärungen und Diskussionen lassen sich wie an einem Scrum-Board führen
14

15. Kommunikationsprotokolle aus Architektursicht
15

16. Kommunikationsprotokolle
● Notwendig, um Informationen zwischen Anwendungen auszutauschen
● In der Regel ab OSI-Layer 5 (Session Layer) implementiert, oft noch auf
Anwendungsprotokollen aufbauend (z.B. HTTP)
● Architekturentscheidungen berühren folgende Punkte:
● Sicherheit
Ist das Protokoll zulässig? Erfüllt es die notwendigen Sicherheitskriterien?
● Performance
Kann der Informationsaustausch schnell genug durchgeführt werden?
● Beschränkungen
Kann der Umfang der Informationen durch das Protokoll übertragen werden?
16

17. Common Object Request Broker Architecture (CORBA)
● Objektorientierte Middleware und plattformübergreifender Protokollstack
● Definiert durch die Object Management Group
● Basiert auf TCP/IP, kann Secure Socket Layer verwenden
● CORBA IIOP Standard-Port 683 (Port 684 für CORBA IIOP over SSL)
● Schnittstellenspezifikation durch Interface Definition Language
● IDL wird mit Compiler in jeweilige Programmiersprache übersetzt
● Stubs und Skeletons entsprechen dem Mediator-Pattern
● Service-basierte Architektur (u.a. Naming Service, Trading Service, Event Service, Life Cycle
Service, Relationship Service)
● Datenbeschreibung als struct, union und sequence, bestehend aus primitiven Typen wie
long, double, string, boolean, enum
● Wurde großteils durch Java und .NET Remoting verdrängt
● Relevante Implementierungen in IBM WebSphere (Basis für Java-Remoting) und ORBit
(verwendet von Mozilla und LibreOffice)
17

18. Remote Procedure Call
● Protokoll zur Interprozesskommunikation, erstmals 1976 beschrieben (RFC 707)
● Aktuelle Version in RFC 1057 und 5531 beschrieben
● Basiert in der Regel auf UDP, prinzipiell aber auch TCP möglich
● Standard-Port für Sun-RPC ist 111, DCE RPC Port ist 135
● Verschiedene Implementierungen, die inkompatibel sind
● Open Network Computing (ONC) RPC (Sun-RPC)
● Distributed Computing Environment (DCE) RPC
● Microsoft RPC (MSRPC), abgeleitet von DCE RPC, Grundlage für DCOM
● Client-Server-Modell, Verzeichnisdienst oder Broadcast notwendig
● Koordination der vom Client initiierten Aufrufe übernimmt ein Portmapper
● Basis von NFS und NIS
● Für die Entwicklung moderner Anwendung kaum von Bedeutung
18

19. Extensible Markup Language Remote Procedure Call (XML-RPC)
● Protokoll auf Basis von HTTP(S) und XML
● Hauptsächlich von Microsoft entwickelt
● Plattformübergreifend und unabhängig von Programmiersprachen durch XML-Format
● Sehr leichtgewichtig, einfach zu implementieren und zu verstehen
● XML-RPC kennt kein NULL
● Datenbeschreibung mit struct und array, bestehend aus primitiven Typen int, double,
boolean, string, datetime.ISO8601 und base64 (für binäre Daten)
● Mittlerweile durch SOAP überholt und im Wesentlichen ersetzt
19

20. Simple Object Access Protocol (SOAP)
● Weiterentwicklung von XML-RPC
● Transportprotokolle HTTP(S), FTP, SMTP oder direkt TCP
● Hautpsächlich von Microsoft entwickelt
● Plattformunabhängig und theoretisch auch unabhängig von Programmiersprachen
● Sehr komplexe Definition von XML-Strukturen zum Nachrichtenaustausch
● Ermöglicht Remote Procedure Calls und Event-basierten Nachrichtenaustausch
● Primäres Ziel ist die schwache Kopplung von Systemen
● Extrem hoher Protokoll-Overhead:
Übertragung eines einzigen Boolean-Wertes benötigt mehrere hundert Bytes
● Relativ langsame Verarbeitung durch Protokoll-Verschachtelung (TCP, HTTP, SOAP), Parser-
Aufwände (SOAP XML) und Verarbeitung (Mapping der Nachricht auf
Programmstrukturen bzw. Methoden)
20

21. Representational State Transfer (ReST)
● Programmierparadigma, geht über Kommunikationsprotokoll hinaus
● Beschreibt Dienste auf Basis von HTTP(S)
● ReST-Services müssen fünf Eigenschaften erfüllen
● Eindeutige Adressierbarkeit
● Unterschiedliche Repräsentationen (ReST macht keine Vorgaben über das
Austauschformat, möglich sind JSON, XML, CSV)
● Zustandslosigkeit (Erbe von HTTP, ermöglicht strikte Trennung zwischen Client und
Server, alle Nachrichten müssen vollständig sein)
● Operationen GET, PUT, DELETE (HTTP-Verben) müssen idempotent sein
● Navigierbarkeit über Ressourcen hinweg (Nutzen von Hyper-Links zur Adressierung)
● ReST nutzt Fähigkeiten des World Wide Web um Dienste zu realisieren, ohne die
Komplexität zu erhöhen (wie das bei SOAP der Fall ist).
● Kann auch als Architekturparadigma verstanden werden und ohne HTTP mit Hilfe von
RPC-Modellen implementiert werden.
21

22. Architektur in agilen Projekten
22

23. Das Architektur-Paradoxon
● Architektur bildet die fachlichen Anforderungen unter Berücksichtigung der
nichtfunktionalen Anforderungen auf technische Strukturen ab
● Üblicherweise sind nicht alle fachlichen Anforderungen zu Beginn bekannt
● Architektur soll stabil sein und sich möglichst nicht ändern
Kann das funktionieren?
● „Es gibt kein deterministisches Verfahren, das in jedem Fall zu guten Software-
Architekturen führt“
(„Effektive Software-Architekturen“, Gernot Starke, 4. Auflage, 2009, Carl Hanser Verlag München)
● „Prognosen sind schwierig, insbesondere wenn sie die Zukunft betreffen.“
(Winston Churchill)
● Software-Architektur basiert im Wesentlichen auf der Erfahrung des Architekten mit
ähnlichen Domänen
23

24. Emergenz und ihre Grenzen
● Die Nicht-Vorhersagbarkeit fachlicher Anforderungen führt zwangsläufig zu Emergenz
● Klassische Vorgehensmodelle lösen das durch Change Requests auf
● Agile Vorgehensmodelle akzeptieren die Emergenz der Architektur als gegeben
● Führt emergente Architektur zu schlechter Software und Unvorhersehbarkeit?
● Software-Architektur muss zu IT-Architektur und Unternehmensarchitektur passen
● Zwischen den unterschiedlichen Architekturen muss abgestimmt werden
● Klassische Architektur versucht oft, viele potentielle Probleme zu lösen
● Agile Architektur verzichtet auf die Lösung zukünftiger Probleme -
das bedeutet nicht, dass sie nicht zukunftsfähig ist!
● Fachliche Anforderungen, die Änderungen der Architektur bedingen, sind entsprechend
aufwändiger → Refactoring muss bei der Implementierung erfolgen
● Emergenz: Architektur entwickelt sich anhand der fachlichen Anforderungen
24

25. Architektur-Pattern erkennen und beschreiben
25

26. Pattern jenseits der GoF
● GoF-Pattern führen nicht zwangsläufig zu gutem Design
● Projekt-Pattern liefern oft elegantere Lösungen für spezifische Problemklassen
● Vorteile von Projekt-Pattern
● Großer Teil der Architektur-Dokumentation kann durch Pattern erzeugt werden
● Einstieg in ein Projekt wird erleichtert
● Refactoring auf Basis von Pattern ist leichter und besser abzuschätzen
● Anwendungsfälle für Projekt-Pattern
● Nutzung von Frameworks im Projekt angleichen
● Architekturvorgaben strukturiert beschreiben
● Architektur-Prototypen in Projekt-Pattern transformieren
26

27. Projektpattern erkennen & beschreiben
● Erkennen (der Notwendigkeit) von Projekt-Pattern
● Gruppen ähnlicher fachlicher Funktionalitäten
● Gruppen ähnlicher Unit-Tests
● Frameworks werden unterschiedlich eingesetzt
● Häufige Erstellung von Prototypen für ähnliche Probleme
● Beschreiben von Projekt-Pattern: Der Pattern-Spannungsbogen
● Umfeld: Wo taucht das Problem auf?
● Problem/Ziel:
Welches Problem adressiert das Pattern? Welches Ziel soll erreicht werden?
● Spannungsfeld:
Warum ist es schwierig, das Problem zu lösen oder das Ziel zu erreichen?
● Lösung: Die Lösung für das Problem, Code-Beispiele, Modelle oder Dokumentation
● Folgen: Vor- und Nachteile der Lösung
(Sehr gut beschrieben in: http://www.tim-wellhausen.de/papers/PatternsSelbstGemacht-Zusammenfassung.pdf)
27

28. Projekt-Pattern anwenden
● Pattern im Projekt kann jeder Stakeholder beisteuern
● Pattern sollten in gleicher Struktur zentral dokumentiert werden
● Architekten sollten Pattern reviewen (und natürlich auch entdecken!)
● Abstimmungsgremium zum Beschluss vorgeschlagener Pattern hat sich bewährt
● Pattern, die unvollständig sind (gerne werden Nachteile vergessen), sollten nicht
zugelassen werden
● Refactoring to Pattern
● Ob ein neues Pattern ein Refactoring nach sich zieht, hängt vom Aufwand ab
(Der wird aber immer nur steigen!)
● Neue Pattern bieten sich zur Einarbeitung für Projekt-Einsteiger an
28

29. Zwischen den Welten: Kommunikation mit
Entwicklern und Anwendern
29

30. Kommunikation im Projekt
● Architekten, die lediglich technische Expertise aufweisen, werden scheitern
● Technische Sachverhalte und Entscheidungen müssen unterschiedlichen Gruppen
vermittelt werden:
● Entwicklern: Architektur muss aus technischer Sicht akzeptiert werden –
Architekten, die nicht programmieren können, stehen auf verlorenem Posten
● Projektleitung: Architektur muss innerhalb des Projektbudgets realisiert werden
können und optimal auf die Bedürfnisse des Projektes eingehen –
Architekten, die nicht betriebswirtschaftlich fundiert entscheiden können,
bekommen an dieser Stelle schnell ein Problem
● Fachbereiche: Architektur muss aus fachlicher Sicht akzeptiert werden –
Fehlendes fachliches Wissen und Verständnis um die Probleme des Fachbereichs und
der Anwender führen zur Ablehnung, unabhängig von der Qualität der Architektur
30

31. Mittel und Wege zur Kommunikation
● Architekten benötigen ein breites Toolset zur Kommunikation
● Einfache Modelle und Screenshots eignen sich sehr gut zur Diskussion mit
Fachbereichen
● Excel-Tabellen die Entscheidungswege objektivieren oder Budgetkalkulationen
transparent machen erfreuen die Projektleitung
● Code-Beispiele können Entwickler im positiven Sinne herausfordern
● Powerpoint-Präsentationen mit den notwendigen Fakten für das Management
● Das wichtigste Werkzeug: Zuhören!
31

32. Fragen
32

33. Was versteht man unter einer Shared-Nothing
Architektur?
33

34. Was versteht man unter einer Shared Nothing Architektur?
● Zum Beispiel das World-Wide-Web
● In einer Shared Nothing Architektur spielen viele Komponenten zusammen, ohne dass sie
sich etwas zentral teilen.
● Shared Nothing Architekturen erreichen damit eine hohe Ausfalltoleranz.
34

35. Wie kann man Transkations-Handling über mehrere
Systeme hinweg realisieren?
35

36. Wie kann man Transkations-Handling über mehrere Systeme hinweg realisieren?
● Verteilte Transaktion benötigt
Koordinator
● Üblicherweise Behandlung nach 2-Phase-
Commit-Protokoll der X/Open XA
● Korrektheit auch bei Ausfall eines
Teilnehmers garantiert
● Grundsätzliches Problem: Blockade
eines Teilnehmers während der
Transaktion
● 3PC-Protokoll: Erhöhung der
Nachrichtenanzahl mit dem Ziel, trotz
eines Ausfalls des Koordinators die
Transaktion beenden zu können
2-Phasen-Commit-Protokoll
(Quelle: http://de.wikipedia.org/wiki/Commit-Protokoll)
36

37. Feature Teams und die Arbeit an mehreren
Komponenten
37

38. Feature Teams und die Arbeit an mehreren Komponenten
● Häufige Diskussion: Feature-Teams, Komponenten-Teams oder Tier-Teams
● Tier-Teams machen Projekte schwer planbar durch Abhängigkeiten zwischen den Tiers
● Komponenten-Teams sind schwer kontinuierlich
● Hohes Know-How innerhalb der Komponente, wenig Know-How außerhalb
● In Agilen Projekten werden generell Feature-Teams eingesetzt
● Generalisten mit Detail-Know-How: cross-funktionale Teams
● Hoher Kommunikationsaufwand bei paralleler Arbeit an mehreren Komponenten
● Geschickter Komponentenschnitt und saubere Architektur erlauben Koordination
● Feature-Teams haben sich für viele Entwicklungsprojekte bewährt
38

39. DevOps und Architektur
39

40. DevOps und Architektur
● DevOps setzt die Agilen Ideale konsequent für den Betrieb von Softwaresystemen fort
● Betriebsführung wird von Beginn an als Stakeholder ins Projekt einbezogen
● Anforderungen der Betriebsführung werden in der Architektur berücksichtigt
● Sinnvoll in Kombination mit Continuous Integration und Contionuous Delivery
● Rollout der Software wird weitestgehend automatisiert („Zero Downtime Deployment“)
● Hohe Änderungsfrequenz („Every Commit is a Release Candidate“)
● Akzeptanz von Offshoring und Parallelität in Entwicklung und Betrieb
● Architektur bildet bei DevOps die Schnittstelle zwischen Entwicklung und Betrieb
● Architektur treibt Automation voran und löst Wissensinseln auf
● Tools von Entwicklung und Betrieb werden vereinheitlicht
● Mehr dazu unter: http://devops.com/
40

41. Verwendung dieser Unterlagen
● Wir stellen diese Unterlagen unter der Creative Commons Lizenz CC-BY-NC-SA zur allen
am Thema Interessierten Verfügung.
● Es ist erlaubt, die Unterlagen unter gleichen Bedingungen zu
● kopieren
● verteilen
● übertragen und
● adaptieren, wenn
● die ursprünglichen Autoren genannt werden und
● die Verwendung nicht zu kommerziellen Zwecken stattfindet.
● Details zur Lizenz sind hier zu finden:
http://creativecommons.org/licenses/by-nc-sa/3.0/
41