Dr. Gernot Starke Architekt. Quality-Driven Software Architecture

Transkript

1 Konferenz Dr. Gernot Starke Architekt Quality-Driven Software Architecture

2 Quality-Driven Software Architecture Dr. Gernot Starke WJAX 2011

3 aktiv Fellow

4 (co) founder of: member of: Fellow

5 Was wollen Benutzer von Software?

6 Was Benutzer wollen... fast correct secure nice'n easy (useable) flexible new features foolproof (robust) User

7 Ein Beispiel

8 Verwaltung von Fotos... Bilder zufügen Keywords ordnen Metadaten (Datum, Ort, Kamerainfos,...)

9 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

10 Domain-Model? id: 0a7c14592bff34518 datum: 24.Mai 2006 ort: Fuerteventura file: dsc02231.jpg album: 2006/urlaub keywords: [family, urlaub]

11 Domain-Model für Beispiel id Foto imgdata Metadaten key value

12 Lösungsansätze iphoto xnview Picasa

13 Fertig?

14 Build what users want: DDD: Domain Driven Design * User Interface Application Domain Infrastructure *) Eric Evans, Addison Wesley 2004

15 Anwender und Entwickler kommunizieren über eine Ubiquitous Language User Interface Application Domain Technische Begriffe Domänenbegriffe Fachjargon (für Entwickler unverständlich) Infrastructure

16 Typen von Domänenobjekten User Interface Application Entity Value Object Service Domain Aggregate Infrastructure Factory Repository

17 Side-Effect Free Functions mache Komposition sicher sichere ab und vereinfache mache Seiteneffekte explizit Assertions "Geschmeidiger Entwurf" (supple design) Intentionrevealing Interfaces Standalone Classes Conceptual Contours beziehe aus Ubiquitous Language modelliere laut Model-Driven Design Namen bestimmen beschreibe Modell mit isoliere Domäne mit Services Layered Architecture Bausteine von DDD Value Objects Entities suche mit Factories erzeuge mit kapsele mit verwalte und validiere mit Repositories erzeuge mit Aggregates suche mit

18 Grails Ruby-on-Rails NakedObjects DDD Trails JMatter Frameworks Romaframework MDAtools Strandz ECO

19 JMatter Beispiel: Konferenzsystem

20 Was wollen andere Stakeholder? fast nice'n easy (useable) correct new features Manager secure flexible foolproof (robust) cost effective new hardware Tester easy to test easy to operate User System operator or administrator

21 Zurück zum Beispiel iphoto Foto id imgdata Metadaten key value

22 Neue Anforderungen (1.Fall) Benutzer im Web jeweils 50 GByte Speicher Suche (nach Keyword / Metadaten) < 1 sec! 24 x 7 mit 99,9% Verfügbarkeit

23 Was nun? Kritische Aufgabenstellungen: Behandlung SEHR großer Datenmengen Skalierung der Benutzerzahlen Hohe Leseperformance Caching, Replikation, BASE statt ACID, Übertragungskosten Foto fast identisches Domain-Model! id imgdata Metadaten key value Owner

24 Neue Anforderungen (2.Fall)... <100 Benutzer, jeweils < 1 GByte Bilddaten sind streng geheim ( military grade security ) Dürfen niemals Unbefugten zugänglich werden

25 Was nun? Kritische Aufgabenstellungen: Crypto, Key-Management Identity-Management, Authentisierung Rechte und Rollen, Administration wieder: fast identisches Domain-Model! Foto id imgdata Owner Metadaten key value

26 Nichtfunktionale Anforderungen sind schwieriger als funktionale. riskanter, aufwändiger, komplizierter, komplexer, teurer, schwerer verständlich.

27 nonfunctional functional Requirements

28 Domain-driven vernachlässigt (oft) nichtfunktionale Qualitätsmerkmale

29 Abhilfe: Qualitätsziele präzise beschreiben Qualität bei Systementwurf explizit berücksichtigen

30 Wie können wir Qualität genauer beschreiben?

31 Qualitätsbaum hierarchische Verfeinerung von Qualität * Qualität Effizienz Portierbarkeit Verstehbarkeit Erlernbarkeit Bedienbarkeit Attraktivität Wartbarkeit Funktionalität Zuverlässigkeit Benutzbarkeit *) z.b. abschreiben von DIN/ISO 9126

32 ... bis zu konkreten Szenarien Performance Data Latency Minimize storage latency on Customer DB to 200 ms Deliver Video in real time Transaction Troughput New Product category Quality Modifiability Change COTS Add CORBA middleware in <20 person-months Change web user interface in <4 person-weeks HW failure Power outage at Site 1 requires traffic redirect to Site 2 in < 3sec Availability Restart after disk failure in <5 sec COTS S/W failure Network failure is detected and recovered in <1.5 mins Security Data confidentiality Credit card transactions are secure 99,999% of time

33 Qualitätsbaum für das Beispiel: (2.Fall) Performanz Datenvolumen Nutzerzahl Sicherheit Geheimhaltung Nur berechtigte Benutzer dürfen Bilddaten entschlüsseln können - Administratoren NICHT Quality Benutzer dürfen keine Bilder sehen, für die sie keine ausdrücklichen Berechtigungen besitzen.

34 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)

35 Wo lernen Sie Taktiken für NFA n? leider nirgendwo vollständig oder systematisch! 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]

36 Qualität mit Methode! Anforderungen klären...qualitätsziele festlegen... Entscheidungen treffen Strukturen entwerfen Technische Konzepte entwerfen Architektur kommunizieren Umsetzung überwachen Architektur bewerten...alles klar?? Der Prozess (

37 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

38 Fazit (1) Qualität ist spezifisch und vielseitig. Sie kommt NIEMALS von allein!

39 Fazit (2) Konzentration auf Fachlichkeit (á la DDD): ist richtig und wichtig aber (oft) nicht ausreichend

40 Fazit (3) Ihre Architektur kann an JEDEM Qualitätsziel scheitern! Starten Sie deshalb mit expliziten Qualitätszielen

41 Fazit (4) Treffen Sie Ihre Architekturentscheidungen Basis eines operationalisierten und priorisierten Qualitätsbaumes

42 und dokumentieren { Treffen Sie Ihre Architekturentscheidungen Basis eines 1. Einleitung und Ziele operationalisierten und priorisierten 1.2 Stakeholder Qualitätsbaumes Fazit (4) 1.1 Aufgabenstellung 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