Was (genau) ist eigentlich

Transkript

1 Frankfurt am Main Stefan Zörner, embarc Nörgeln ist einfach #ittage Aber was (genau) ist eigentlich? Was (genau) ist eigentlich? Jedes interessante Softwaresystem hat eine Softwarearchitektur. Diese ist kunstvoll geplant oder zufällig entstanden, meist aber irgendwas dazwischen. Hätte man es anders machen sollen? In diesem Vortrag stelle ich vor, wann und wie Ihr Eure Softwarearchitektur bewertet! Seid Ihr auf dem richtigen Weg? Können Eure Architekturideen in der Umsetzung aufgetretene Probleme effektiv lösen? Helfen diese bei der Erreichung Eurer Ziele oder behindern sie diese eher? kann Sicherheit schaffen und Risiken aufzeigen und damit helfen die Aufwände im Vorhaben zu fokussieren. Ihr lernt qualitative und quantitative Bewertungsmethoden kennen: Was argumentative, Workshop-basierte Verfahren wie ATAM leisten thematisiere ich ebenso wie welche Aspekte Eurer Architekturziele sich mit Messungen verknüpfen lassen. 2 1

2 Stefan Zörner n Softwareentwickler + -architekt bei embarc in Hamburg n Vorher oose, IBM, Mummert + Partner, Bayer AG, Schwerpunkte: n Softwarearchitektur (Entwurf, Bewertung, Dokumentation) n Java Technologien è xing.to/szr 3 Agenda 1 Architektur: Sehr annehmbar (Note: 4.5). 2 Qualitative Bewertungsmethoden 3 Quantitative Bewertungsmethoden 4 Wann was und wozu? 5 Fazit und weitere Informationen 4 2

3 Agenda 1 Architektur: Sehr annehmbar (Note: 4.5). 2 Qualitative Bewertungsmethoden 3 Quantitative Bewertungsmethoden 1 4 Wann was und wozu? 5 Fazit und weitere Informationen 5 Montag Morgen. 6 3

4 Montag Morgen. 09:00 Uhr. Das neue Teammitglied beginnt seine Arbeit... 11:00 Uhr.... und hat viele Fragen. Warum habt Ihr das denn so gemacht? Hätte man das nicht besser so gemacht? Was genau heißt hier besser? In der Softwareentwicklung? 7 Mission Statement. (für diesen Vortrag) Klären, was (genau) ist. Diskutieren, welche unterschiedlichen Ansätze und Methoden es dazu gibt. Aufzeigen, wann eine Methode welchen Nutzen stiftet. 8 4

5 Was ist Softwarearchitektur? Softwarearchitektur := wichtige Entscheidungen wichtig := n fundamental (betrifft viele) n im weiteren Verlauf nur schwer zu ändern n entscheidend für den Erfolg des Softwaresystems 9 Themen für Entscheidungen Zerlegung Module und Abhängigkeiten Komponentenbildung... Technologie-Stack Programmiersprache(n), Bibliotheken, Frameworks Middleware (Kommunikation, Applikationsserver...) Querschnittsthemen (Persistenz, Oberfläche...)... Zielumgebung Wo läuft die Software? (Endanwender vs. RZ vs. Cloud) Verteilungsaspekte (Redundanz, Clustering) Virtualisierung

6 Softwarearchitektur bewerten? 11 Gegeneinanderhalten Architektur / Entwurf Entscheidungen, Konzepte, Modelle,... Best Practices Stile und Muster, Prinzipien, Methoden und Vorgehen,

7 Gegeneinanderhalten Architekturrelevante Anforderungen Vorgaben, Qualitätsziele,... Architektur / Entwurf Entscheidungen, Konzepte, Modelle,... Best Practices Stile und Muster, Prinzipien, Methoden und Vorgehen, Gegeneinanderhalten Architekturrelevante Anforderungen Vorgaben, Qualitätsziele,... Architektur / Entwurf Entscheidungen, Konzepte, Modelle,... Best Practices Stile und Muster, Prinzipien, Methoden und Vorgehen,... Umsetzung Quelltext, Implementierung, laufendes System,

8 Gegeneinanderhalten Architekturrelevante Anforderungen Vorgaben, Qualitätsziele,... Architektur / Entwurf Entscheidungen, Konzepte, Modelle,... Best Practices Stile und Muster, Prinzipien, Methoden und Vorgehen,... Umsetzung Quelltext, Implementierung, laufendes System, Agenda 2 1 Architektur: Sehr annehmbar (Note: 4.5). 2 Qualitative Bewertungsmethoden 3 Quantitative Bewertungsmethoden 4 Wann was und wozu? 5 Fazit und weitere Informationen 16 8

9 Einflüsse auf Entscheidungen - schränken die Lösung ein - schließen Optionen aus Rahmenbedingungen technisch organisatorisch Qualitätsanforderungen Benutzbarkeit Sicherheit... - formen die Lösung - nachher schwierig einzubauen 17 Qualitätsmerkmale Zuverlässigkeit (Reliability) Ist das System verfügbar, tolerant gegenüber Fehlern, nach Abstürzen schnell wieder hergestellt?... Funktionalität (Functionality) Sind die berechneten Ergebnisse korrekt / exakt, ist die Funktionalität angemessen?... Begriffe nach Norm ISO Wartbarkeit (Maintainability) Ist die Software leicht zu ändern, erweitern, testen, verstehen? Lassen sich Teile wiederverwenden?... Sicherheit (Security) Ist das System sicher vor Angriffen? Sind Daten und Funktion vor unberechtigtem Zugriff geschützt?... Effizienz (Performance) Antwortet die Software schnell, hat sie einen hohen Durchsatz, einen geringen Ressourcenverbrauch?... Benutzbarkeit (Usability) Ist die Software intuitiv zu bedienen, leicht zu erlernen, attraktiv? Kompatibilität (Compatibility) Ist die Software konform zu Standards, arbeitet sie gut mit anderen zusammen? Portabilität (Portability) Ist die Software leicht auf andere Zielumgebungen (z.b. anderes OS) übertragbar? 18 9

10 Beispiel: Atlassian Confluence Qualitätsziele (aka Architekturziele) Ziel 1. Leicht zu betreiben 2. Gute Benutzbarkeit 3. Hohe Zuverlässigkeit 4. Sicherheit der Inhalte 5. Gute Wartbarkeit Beschreibung Für ein Team ist es einfach mit Confluence zu starten. Confluence ist effizient und intuitiv von allen Team-Mitgliedern zu verwenden. Das System steht den Anwendern jederzeit zur Verfügung. Inhalte sind vor unberechtigtem Zugriff und Veränderung geschützt. Confluence ist leicht zu ändern und um Funktionalität zu erweitern. Die Reihenfolge gibt eine Orientierung bezüglich der Wichtigkeit. 19 CAPTCHA* (*) Completely Automated Public Turing test to tell Computers and Humans Apart. Quelle: PHP Captcha Library 20 10

11 Eingabe eines Kennwortes Username StefanZ Password Username StefanZ Password geheim! Typische Wechselwirkung Benutzbarkeit (Usability) Ist die Software intuitiv zu bedienen, leicht zu erlernen, attraktiv? ì Sicherheit (Security) Ist das System sicher vor Angriffen? Sind Daten und Funktion vor unberechtigtem Zugriff geschützt?... î Benutzer empfinden Sicherheitsmaßnahmen als störend (z. B. Passworteingabe, CAPTCHAs) 22 11

12 Typische Wechselwirkung Effizienz (Performance) Antwortet die Software schnell, hat sie einen hohen Durchsatz, einen geringen Ressourcenverbrauch?... ì Portabilität (Portability) Ist die Software leicht auf andere Zielumgebungen (z.b. anderes OS) übertragbar? î Abstraktionen (z. B. Schichten) reduzieren die Möglichkeit plattformspezifischer Optimierungen Qualitätsmerkmale hängen voneinander ab. Entscheidungen führen zu Kompromissen (engl. Tradoff ). 23 Qualitative ATAM Architecture tradeoff analysis method n verbreitetste Methode zur qualitativen Bewertung von Softwarearchitektur n früh anwendbar n szenarienbasiert 24 12

13 Was ist ein Szenario? Ein (Qualitäts-)Szenario... n... ist ein kurzer Text (1-3 Sätze). n... beschreibt beispielhaft die Verwendung des Systems, und zwar so dass ein Qualitätsmerkmal die Hauptrolle spielt. Wie konkret?! Man muss sinnvoll drüber reden können. Man muss es (theoretisch) überprüfen können. (Kein Abnahmekriterium, kein Testfall!) 25 Szenarien Typische Bestandteile Beispiel für ein Qualitätsszenario Quelle Antwort-Maß Ein versierter Java-Entwickler beabsichtigt Confluence um ein einfaches Macro zu erweitern. Das Macro steht dem Team nach einem Personentag zur Verfügung

14 27 Qualitative Methoden Stärken n binden Stakeholder optimal ein und fördern so den Austausch n früh anwendbar n passen auf alle Qualitätsmerkmale Schwächen n qualitative Durchsprache ist kein Messen ( Restrisiko bleibt) n Workshops nicht trivial in der Durchführung (Planung, Moderation...) 28 14

15 Agenda 1 Architektur: Sehr annehmbar (Note: 4.5). 2 Qualitative Bewertungsmethoden 3 Quantitative Bewertungsmethoden 3 4 Wann was und wozu? 5 Fazit und weitere Informationen 29 Warum quantitative Ansätze? n Qualitative Methoden setzen auf Fokussierung, die Durchsprache von Lösungsansätzen und die Erfahrung und Argumente der Workshop-Beteiligten. n Eine gewisse Unsicherheit bleibt ( Restrisiko ). Quantitative Bewertungsansätze setzen auf vermeintlich belastbarere Fakten. Sie vermessen die Lösung: Umsetzung Quelltext der Software die Struktur der Elemente, deren Beziehungen untereinander Leistungswerte des laufenden Systems 30 15

16 Quantitative Ansätze (1) Architektur / Entwurf Umsetzungsprüfung z.b. geplante Zerlegung und Abhängigkeiten mit der Implementierung abgleichen Beispiel-Tools: Sonargraph Structure101 Umsetzung 31 Beispiel: Struktur in Confluence 32 16

17 Quantitative Ansätze Architektur / Entwurf Best Practices Umsetzungsprüfung z.b. geplante Zerlegung und Abhängigkeiten mit der Implementierung abgleichen Metriken und Regeln z.b. zu Testüberdeckung, Clone Coverage, Kohäsion und Kopplung, Kodierrichtlinien... Beispiel-Tools: Sonargraph Structure101 Umsetzung Beispiel-Tools: SonarQube Teamscale 33 Beispiel: Metriken für Confluence 34 17

18 Quantitative Ansätze Architektur / Entwurf Architekturrelevante Anforderungen Best Practices Umsetzungsprüfung z.b. geplante Zerlegung und Abhängigkeiten mit der Implementierung abgleichen Direkte Zielüberprüfung z.b. Last- und Performancetests, Monitoring, Logging... Metriken und Regeln z.b. zu Testüberdeckung, Clone Coverage, Kohäsion und Kopplung, Kodierrichtlinien... Beispiel-Tools: Sonargraph Structure101 Umsetzung Beispiel-Tools: SonarQube Teamscale 35 Quantitative Methoden Stärken n Messungen sind leicht automatisierbar und wiederholbar n Wenig Bauchgefühl, Zahlen sind gute Argumente Schwächen n Vergleichsweise spät einsetzbar n Messungen können nicht alle Qualitätsmerkmale gut erfassen n Gefahr der Missdeutung und Fehlleitung 36 18

19 Agenda 1 Architektur: Sehr annehmbar (Note: 4.5). 2 Qualitative Bewertungsmethoden 3 Quantitative Bewertungsmethoden 4 4 Wann was und wozu? 5 Fazit und weitere Informationen 37 Wann helfen Architektur-Reviews? Eine Neuentwicklung steht an und erste Lösungsansätze stehen im Raum. t 38 19

20 Neuentwicklung Anlass Eine Neuentwicklung steht an und erste Lösungsansätze stehen im Raum. Leitfrage Seid Ihr und Euer Team auf dem richtigen Weg? Möglicher Bewertungsansatz Team-interner Workshop. Schlanke Szenarien-basierte Durchsprache der Architekturvision, um Fokus für Konzeption/ Entwicklung zu setzen ( Discovery Review ). 39 Wann helfen Architektur-Reviews? Eine Neuentwicklung steht an und erste Lösungsansätze stehen im Raum. t Unterschiedliche Stakeholder verfolgen widersprüchliche Ziele mit Eurer Software

21 Widersprüchliche Ziele Anlass Unterschiedliche Stakeholder verfolgen widersprüchliche Ziele mit Eurer Software. Leitfrage Wie konkretisiert und priorisiert Ihr deren Wünsche? Möglicher Bewertungsansatz Workshop gemeinsam mit maßgeblichen Stakeholdern, um Klarheit bezüglich Ziele zu schaffen (ggf. Quality Attribute Workshop). 41 Wann helfen Architektur-Reviews? Eine Neuentwicklung steht an und erste Lösungsansätze stehen im Raum. Das Management hat das Vertrauen in Eure Lösung verloren. t Unterschiedliche Stakeholder verfolgen widersprüchliche Ziele mit Eurer Software

22 Vertrauen verloren Anlass Das Management hat das Vertrauen in Eure Lösung verloren. Leitfrage Wie gewinnt Ihr es zurück und strahlt Sicherheit aus? Möglicher Bewertungsansatz Qualitative Bewertung mit projektfremder Unterstützung und Management-Beteiligung, um Stärken und Kompromisse sichtbar zu machen. 43 Wann helfen Architektur-Reviews? Eine Neuentwicklung steht an und erste Lösungsansätze stehen im Raum. Das Management hat das Vertrauen in Eure Lösung verloren. t Unterschiedliche Stakeholder verfolgen widersprüchliche Ziele mit Eurer Software. Größerer Umbaumaßnahmen in der Software stehen an

23 Umbaumaßnahmen Anlass Größerer Umbaumaßnahmen in der Software stehen an. Leitfrage Wie wählt Ihr passende Lösungsansätze nachvollziehbar aus? Möglicher Bewertungsansatz Umfassende qualitative Analyse, flankiert mit quantitativen Ansätzen. Verknüpfung von Problemen mit Maßnahmen, siehe auch Cost Benefit Analysis Method (CBAM), aim42. Priorisierung. 45 Agenda 5 1 Architektur: Sehr annehmbar (Note: 4.5). 2 Qualitative Bewertungsmethoden 3 Quantitative Bewertungsmethoden 4 Wann was und wozu? 5 Fazit und weitere Informationen 46 23

24 tl;dr (too long; didn t read) Softwarearchitektur beschäftigt sich mit grundlegenden, später schwer änderbaren Entscheidungen. Um eine Architektur zu bewerten haltet Ihr sie gegen einen Maßstab (vor allem: Ziele). Das geht qualitativ (Durchsprache) und quantitativ (Tools, Messen). Eine frühe Bewertung mit qualitativen Mitteln deckt Risiken auf und schafft Klarheit. Spät aufgedeckte Probleme lassen sich oft nur noch als technische Schulden abheften. 47 Online-Artikel zum Thema è

25 Spicken erlaubt! Unsere Architektur-Spicker beleuchten die konzeptionelle Seite der Softwareentwicklung. è /architektur-spicker/ 49 Spicken erlaubt! Unsere Architektur-Spicker beleuchten die konzeptionelle Seite der Softwareentwicklung. ç Spicker #4: Architektur-Reviews PDF, 4 Seiten Kostenloser Download. Was leisten ArchitekturReviews? Welche Methoden und Werkzeuge helfen? Wer sollte wann und wie oft in Reviews eingebunden sein? è /architektur-spicker/ 50 25

26 Vielen Dank. Ich freue mich auf Eure xing.to/szr DOWNLOAD FOLIEN: è/blog/ 26