1
Softwarequalität
Architektur & Qualität
Gerrit Beine, [email protected]
Prof. Dr. Wolfgang [email protected]
2
Aufgaben von Software-Architektur
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
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
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
6
Architektur, Conway's Law und das Problem der Komponententeams
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.
8
Conway's Law und Modellebenen
Sicht Artefakte Beziehungen
Geschäftsobjektsicht Business Objects, repräsentiert durch Klassen, sehr hohes Abstraktionsniveau
Ausschließlich zwischen Business Objects
Anforderungssicht Requirements, Functional & Non-Functional
Verbindung zwischen Functional & Non-Functional Requirements,Abhängigkeiten zu Business Objects
Anwendungsfallsicht Use Cases, ActorsManchmal hier sinnvoll: Fachklassenmodelle
Use Cases realisieren RequirementsUse Cases benötigen Business Objects (oder Fachklassen)
Fachliche Architektur Components, Dependencies, Fachlich orientiert, Keine technologische Aspekte
Component realisiert Use Case
Technische Architektur Components, Dependencies, Technische Aspekte sichtbar, Grundlage für Build Process
Component realisiert Component aus Fachlicher Architektur
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.
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.
11
Architektur-Dokumentation
12
Die vier Sichten von Architekturdokumentation
● KontextabgrenzungEinbettung in der Umgebung, Schnittstellen zu Nachbarsystemen, System ist Blackbox
● BausteinsichtInterne Sicht des Systems, statische Strukturen, Abhängigkeiten zwischen Komponenten
● LaufzeitsichtInterne Sicht, Verhaltensbeschreibungen, Interaktion der Bausteine zur Laufzeit, Beschreibung des dynamischen Strukturen
● VerteilungssichtExterne Sicht, Topologie des Systems, Infrastruktur, Hardware, Deployment
Kontextabgrenzung
Laufzeitsichten
Bausteinsichten
Verteilungssichten
Vier Arten von Sichten(Nach „Effektive Software-Architekturen“, Gernot Starke, 4. Auflage, 2009,Carl Hanser Verlag München)
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
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
15
Kommunikationsprotokolle aus Architektursicht
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:
● SicherheitIst das Protokoll zulässig? Erfüllt es die notwendigen Sicherheitskriterien?
● PerformanceKann der Informationsaustausch schnell genug durchgeführt werden?
● BeschränkungenKann der Umfang der Informationen durch das Protokoll übertragen werden?
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)
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
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
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)
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.
22
Architektur in agilen Projekten
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
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
25
Architektur-Pattern erkennen und beschreiben
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
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)
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
29
Zwischen den Welten: Kommunikation mit Entwicklern und Anwendern
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
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!
32
Fragen
33
Was versteht man unter einer Shared-Nothing Architektur?
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.
35
Wie kann man Transkations-Handling über mehrere Systeme hinweg realisieren?
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)
37
Feature Teams und die Arbeit an mehreren Komponenten
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
39
DevOps und Architektur
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/
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/
Recommended
