Quality Driven Software Architecture

Qualitätsanforderungen an Software systematisch erreichen - durch "Quality Driven Software Architecture".

Die Methode basiert auf zwei einfachen Ansätzen:
1.) Qualitätsziele durch Szenarien konkretisieren (ähnlich ATAM)
2.) Szenarien durch Maßnahmen oder Strategien angehen

Transcript

1. Quality-Driven Software Architecture Dr. Gernot Starke www.arc42.de WJAX 2011
2. aktiv Fellow
3. member of: (co) founder of: Fellow
4. Was wollen Benutzer von Software?
5. Was Benutzer wollen... fast flexible foolproof (robust) nice'n easy (useable) correct secure User new features
6. Ein Beispiel
7. Verwaltung von Fotos... Bilder zufügen ordnen Keywords Metadaten (Datum, Ort, Kamerainfos,...)
8. Use-Cases für Beispiel Foto hinzufügen / löschen Fotos anzeigen Metadaten für Foto ändern (Ort, Datum, Keywords etc.) Album anlegen / ändern / löschen Fotos suchen
9. Domain-Model? datum: 24.Mai 2006 ort: Fuerteventura file: dsc02231.jpg album: 2006/urlaub keywords: [family, urlaub] id: 0a7c14592bff34518
10. Domain-Model für Beispiel Foto id imgData Metadaten key value
11. Lösungsansätze iPhoto xnView Picasa
12. Fertig?
13. Build what users want: DDD: Domain Driven Design User Interface Application Domain Infrastructure * *) Eric Evans, Addison Wesley 2004
14. Anwender und Entwickler kommunizieren über eine „Ubiquitous Language“ User Interface Application Domain Infrastructure Technische Begriffe Fachjargon (für Entwickler unverständlich) Domänen- begriffe
15. Typen von „Domänenobjekten“ User Interface Application Domain Infrastructure Entity Value Object Service Aggregate Repository Factory
16. Model-Driven Design Services Entities Layered Architecture isoliere Domäne mit beschreibe Modell mit Value Objects Ubiquitous Language modelliere laut Intention- revealing Interfaces "Geschmeidiger Entwurf" (supple design) Bausteine von DDD Side-Effect Free Functions Assertions Standalone Classes Conceptual Contours Namen bestimmen beziehe aus sichere ab und vereinfache mache Seiteneffekte explizit mache Komposition sicher Repositories Factories Aggregates verwalte und validiere mit suche mit erzeuge mit kapsele mit erzeuge mit suche mit
17. DDD Frameworks NakedObjects JMatter Roma- framework Ruby-on-Rails Strandz Trails ECO Grails MDA- tools www.rails.org www.nakedobjects.org www.jmatter.org www.romaframework.org www.grails.org www.trailsframework.org www.capableobjects.com www.strandz.org
18. Beispiel: Konferenzsystem JMatter
19. fast flexible foolproof (robust) nice'n easy (useable) correct secure User easy to operate System operator or administrator cost effective Manager new features new hardw are easy to test Tester Was wollen andere Stakeholder?
20. Zurück zum Beispiel iPhoto Foto id imgData Metadaten key value
21. Neue Anforderungen (1.Fall)... 100.000.000 Benutzer im Web jeweils 50 GByte Speicher Suche (nach Keyword / Metadaten) < 1 sec! 24 x 7 mit 99,9% Verfügbarkeit
22. Was nun? Kritische Aufgabenstellungen: Behandlung SEHR großer Datenmengen Skalierung der Benutzerzahlen Hohe Leseperformance Caching, Replikation, BASE statt ACID, Übertragungskosten Foto id imgData Metadaten key value Owner „fast“ identisches Domain-Model!
23. Neue Anforderungen (2.Fall)... <100 Benutzer, jeweils < 1 GByte Bilddaten sind streng geheim („military grade security“) Dürfen niemals Unbefugten zugänglich werden
24. Was nun? Kritische Aufgabenstellungen: Crypto, Key-Management Identity-Management, Authentisierung Rechte und Rollen, Administration Foto id imgData Metadaten key value Owner wieder: „fast“ identisches Domain-Model!
25. Nichtfunktionale Anforderungen sind schwieriger als funktionale. riskanter, aufwändiger, komplizierter, komplexer, teurer, schwerer verständlich.
26. non- functional functional Requirements
27. Domain-driven vernachlässigt (oft) nichtfunktionale Qualitätsmerkmale
28. Abhilfe: • Qualitätsziele präzise beschreiben • Qualität bei Systementwurf explizit berücksichtigen
29. Wie können wir „Qualität“ genauer beschreiben?
30. Qualitätsbaum hierarchische Verfeinerung von „Qualität“ Qualität Funktiona- lität Zuverlässig- keit Benutzbar- keit Effizienz Wartbarkeit Portierbar- keit * z.B. abschreiben von DIN/ISO 9126 *) Versteh- barkeit Erlern- barkeit Bedien- barkeit Attraktivität
31. ... bis zu konkreten Szenarien Quality Performance Modifiability Availability Security Data Latency Transaction Troughput Minimize storage latency on Customer DB to 200 ms Deliver Video in real time New Product category Change COTS Add CORBA middleware in <20 person-months Change web user interface in <4 person-weeks HW failure COTS S/W failure Power outage at Site 1 requires traffic redirect to Site 2 in < 3sec Restart after disk failure in <5 sec Network failure is detected and recovered in <1.5 mins Data confidentiality Credit card transactions are secure 99,999% of time
32. Qualitätsbaum für das Beispiel: (2.Fall) Quality Performanz Sicherheit Daten- volumen Nutzerzahl ...... ...... Geheimhaltung Nur berechtigte Benutzer dürfen Bilddaten entschlüsseln können - Administratoren NICHT Benutzer dürfen keine Bilder sehen, für die sie keine ausdrücklichen Berechtigungen besitzen.
33. Q-Szenario und mögliche Taktiken... Ziel / Szenario: Nur berechtigte Benutzer dürfen Bilddaten entschlüsseln können - Administratoren NICHT. Maßnahme: Schlüssel (private-key) zum Entschlüsseln nicht auf dem Server speichern. Smartcard Secure-Remote-Password-Protocol (SRP)
34. Wo lernen Sie Taktiken für NFA‘n? Patterns, Pattern-Families POSA-Bücher (Patterns of Software Architecture), insbesondere zu Security, Resource-Management, Distribution, Concurrency Global Analysis [Hofmeister] Quality Tactics [Bass, Clements, Kazman] leider nirgendwo vollständig oder systematisch!
35. Qualität mit Methode! Anforderungen klären ...Qualitätsziele festlegen... Strukturen entwerfen Technische Konzepte entwerfen Architektur kommunizieren Architektur bewerten Umsetzung überwachen Entscheidungen treffen ...alles klar?? Der Prozess (www.arc42.de)
36. QDA: Quality Driven Architecture Ergänzt Domain Driven Design um die explizite und frühzeitige Beachtung von Qualitätsanforderungen durch Festlegung von Architekturzielen durch Präzisierung der Architekturziele mittels eines Qualitätsbaumes durch Strategien zur Erreichung von Qualitätsmerkmalen
37. Fazit (1) Qualität ist spezifisch und vielseitig. Sie kommt NIEMALS von allein!
38. Fazit (2) Konzentration auf Fachlichkeit (á la DDD): ist richtig und wichtig aber (oft) nicht ausreichend
39. Fazit (3) Ihre Architektur kann an JEDEM Qualitätsziel scheitern! Starten Sie deshalb mit expliziten Qualitätszielen
40. Fazit (4) Treffen Sie Ihre Architektur- entscheidungen Basis eines operationalisierten und priorisierten Qualitätsbaumes
41. Treffen Sie Ihre Architektur- entscheidungen Basis eines operationalisierten und priorisierten Qualitätsbaumes Fazit (4) und dokumentieren 1. Einleitung und Ziele 1.1 Aufgabenstellung 1.2 Stakeholder 1.3. Qualitätsziele 2. Randbedingungen 3. Kontextabgrenzung 4. Lösungsstrategie 5. Bausteinsicht 6. Laufzeitsicht 7. Verteilungssicht 8. Typische Strukturen und Muster 9. Technische Konzepte 10. Entwurfsentscheidungen 11. Qualitätsszenarien V5.0 {