Thomas Schoen hello2morrow GmbH Six-Sigma für Software Architekten
Komplexität kann leicht außer Kontrolle geraten 2010 hello2morrow GmbH 2
Was ist technische Softwarequalität? Technische (interne, strukturelle) Softwarequalität beeinflusst: Testbarkeit Erweiterbarkeit Wartbarkeit Verständlichkeit Technische Qualität kann nicht allein durch Testen herbeigeführt werden Technische Qualität hat die folgenden Aspekte: Architektur und Abhängigkeitsstruktur des Programmcodes Modularisierung, Grösse, Komplexität, Programmdesign Einhaltung von Programmierregeln Zusammen bestimmen diese Aspekte die technische Qualität eines Softwaresystems 2010 hello2morrow GmbH 3
Symptome der Erosion technischer Qualität (nach Robert C. Martin) Rigidity (Änderungsresistenz) The system is hard to change because every change forces many other changes. Fragility (Zerbrechlichkeit) Tendency that every change in the software produces many errors at different locations in the code (which might be conceptually unrelated). Immobility (Unbeweglichkeit) Inability to reuse software components in other projects or in other parts of the same project. Viscosity (Mühsamkeitsfaktor) Viscosity means that it is a lot harder to implement a change according to the intended design than by using workarounds and hacks. Software starts to rot like a piece of bad meat 2010 hello2morrow GmbH 4
Gründe für die Erosion der technischen Qualität Erosion ist ein automatischer Prozess Technische Qualität wird gar nicht erst gemessen Das Management betrachtet Softwaresysteme als Black Box Komplexität wächst schneller als das System Unerwünschte Abhängigkeiten werden unbemerkt eingeführt Mangelnde Kommunikation in (verteilten) Entwicklungsteams Zeitdruck führt oft zu bewussten Qualitätseinbussen 2010 hello2morrow GmbH 5
Kosten wegen Qualitäts-Erosion Anonymisierte Studie: Vergleich von definierten Erweiterungsmassnahmen in demselben Softwaresystem, das in zwei Versionen vorlag: Als unbehandeltes System mit viel Architekturerosion und als restrukturiertes, architekturkonformes System Kosten für Erweiterung 70 60 50 40 30 20 10 Erweiterungsmassnahme erodiertes System Erweiterungsmassnahme architekturkonformes System 0 Projekt-Lebensdauer 2010 hello2morrow GmbH 6
Die Abhilfe Six Sigma für Software Six Sigma ist eine standardisierte Methode zur Verbesserung von Prozessen Systematische Verringerung von Abweichungen Systematische Optimierung der Prozesse in Richtung der Qualitätsanforderungen Six Sigma basiert auf einer genauen Defnition und Überprüfung der Qualität DMAIC-Zyklus 2010 hello2morrow GmbH 7
Wie misst man technische Softwarequalität? Architektur Anzahl der Abweichungen von Architekturvorgaben Struktur Anzahl der zyklischen Packages, Source-Files, JAR-Files. Größe der Zyklengruppen, Stärke der Kopplung Modularisierung, Grösse, Komplexität, (Programmdesign) Metriken mit Definition einer Menge von Schwellwerten (Qualitätsmodell) und Messung der Anzahl der Verletzungen Programmierregeln Benutzung von Coding-Rule-Checkern (z.b. Checkstyle, Findbugs, PMD); Messung der Anzahl von Regelverletzungen 2010 hello2morrow GmbH 8
Architekturregeln benötigen eine logische Soll-Architektur 2010 hello2morrow GmbH 9
Zweidimensionale Softwarearchitektur 1. Dimension: horizontale Schichtenarchitektur Strukturiert ein Softwaresystem nach technischen Kriterien Klassisches, hierarchisches Architekturmodell: Obere Schichten dürfen Programmcode aus unteren Schichten nutzen, aber nicht umgekehrt GUI Controller Data 2010 hello2morrow GmbH 10
Zweidimensionale Softwarearchitektur Was ist mit der Strukturierung der Geschäftslogik? Die technische Struktur bildet lediglich die Basis für die zu implementierende Geschäftslogik (Business Logic) Normalerweise hat die Geschäftslogik ebenfalls eine Struktur und besteht aus einzelnen Anwendungsfällen (Use Cases) Die Anwendungsfälle haben untereinander klar definierte Abhängigkeiten Die Anwendungsfälle sind unabhängig von der technischen Schichtung strukturiert sie sind orthogonal zur technischen Schichtung. 2010 hello2morrow GmbH 11
Zweidimensionale Softwarearchitektur 2. Dimension: vertikale Säulenarchitektur Strukturiert ein Softwaresystem nach fachlichen Kriterien (z.b. Use Cases) Auch hier gibt es häufig eine klare Hierarchie (z.b. von links nach rechts) Use Case: Use Case: Use Case: Use Case: Contract Customer User Common 2010 hello2morrow GmbH 12
Zweidimensionale Softwarearchitektur Architecture Grid horizontale + vertikale Schnitte Ihr Softwaresystem Schnittpunkte: Natürliche Subsysteme GUI Controller Logic Contract Customer User Common Data Schritt 1: Zerlege das System in horizontale Schichten nach technischen Kriterien Schritt 2: Zerlege das System in vertikale Säulen nach fachlichen Kriterien (Geschäftslogik) Schritt 3: Definiere die erlaubten/verbotenen Abhängigkeiten zwischen Schichten und Säulen Das zweidimensionale Architekturkonzept ist inbesondere gut für betriebswirtschaftliche Applikationen bei Banken, Versicherungen, Logistik, Verwaltung geeignet. 2010 hello2morrow GmbH 13
Architekturregeln müssen automatisch prüfbar sein 2010 hello2morrow GmbH 14
Softwarearchitektur-Monitoring Definition SOLL-Architektur Analyse IST-Architektur Abgleich von SOLL / IST- Architektur Anpassung / Erweiterung Architekturentwurf Planung der Code-Restrukturierung Architekturverifikation am Entwicklerarbeitsplatz Implementierung 2010 hello2morrow GmbH 15
Metric distance (Robert C. Martin) D = A + I 1 Value range [-1.. +1] Negative values are in the Zone of pain Positive values belong to the Zone of uselessness Good values are close to zero (e.g. -0,25 to +0,25) 12:20 2005-2010, hello2morrow 16 2010 hello2morrow GmbH 16
Zyklische Abhängigkeiten sind schädlich "The dependencies between packages must not form cycles." Robert C. Martin in "Agile Software Development" "Guideline: No Cycles between Packages. If a group of packages have cyclic dependency then they may need to be treated as one larger package in terms of a release unit. This is undesirable because releasing larger packages (or package aggregates) increases the likelihood of affecting something." Craig Larman in "Applying UML And Patterns" "Cyclic physical dependencies among components inhibit understanding, testing and reuse. " John Lakos in "Large-Scale C++ Software Design" 2010 hello2morrow GmbH 17
Zyklische Abhängigkeiten sind schädlich level C 3 C B 2 B A 1 A Case 1: cyclic Case 2: acyclic Um die Funktionalität einer Komponente zu verstehen muss man alle Komponenten verstehen Man kann alle Komponenten nur gemeinsam aber nicht einzeln testen Es gibt nur eine Möglichkeit der Wiederverwendung: Alle Komponenten aus dem Zyklus wiederverwenden Eine Impact-Analyse für eine Änderung ist schwierig ( eventuell müssen wir alle Komponenten ändern ) 2010 hello2morrow GmbH 18
Große Package Zyklengruppe ("Code Tumor") 2010 hello2morrow GmbH 19
Beispiel für eine zyklische Abhängigkeit Presentation Model Main AlarmClock AlarmHandler AlarmToConsole AlarmToFile 2010 hello2morrow GmbH 20
Aufbrechen der zyklischen Abhängigkeit Presentation <<bottom>> Model Main AlarmClock AlarmHandler <<interface>> IAlarmHandler AlarmToConsole AlarmToFile 2010 hello2morrow GmbH 21
Wie misst man den Kopplungsgrad? Component Dependency: Anzahl der direkten und indirekten (transitiven) Abhängigkeiten einer Komponente Metrik ACD = Average Component Dependency Die durchschnittliche Anzahl der direkten und indirekten Abhängigkeiten pro Komponente 6 6 3 Cycles 3 3 6 6 1 1 1 1 1 1 6 1 2 3 2 Cumulative Component Dependency = 15 ACD = 15/6 = 2,5 CCD = 26 (Cycles) ACD = 26/6 = 4,33 CCD=12 ACD = 12/6 = 2 Metrik NCCD = Normalized cumulative component dependency Verhältnis der CCD zur CCD eines gleichgrossen Systems, das als balanced-binary-tree strukturiert ist 2010 hello2morrow GmbH 22
Qualitätsmodell für die Zieldefinition Architekturvorgaben Regeln für die Struktur Auswahl von geeigneten Metriken Festlegen von passenden Metrikschwellwerten Auswahl von Programmierregeln und Richtlinien Ein Qualitätsmodell ist anpasst an die Applikationsdomäne: projekt- oder firmenspezifisch Ein Qualitätsmodell muss in der Praxis funktionieren 2010 hello2morrow GmbH 23
Ein einfaches, aber nützliches und funktionierendes Qualitätsmodell Rule 1: Define a cycle free logical architecture down to the level of subsystems and a strict and consistent package naming convention Rule 2: Do not allow cyclic dependencies between different packages Rule 3: Keep the coupling low (NCCD < 7) Rule 4: Limit the size of a Java package (e.g. less than 50 classes) Rule 5: Limit the size of Java files (700 LOC is a reasonable value) Rule 6: Limit the cyclomatic complexity of methods (e.g. < 20) (number of possible control paths through a method) Rule 7: Avoid long duplicated code sequences: no copies of classes or packages 2010 hello2morrow GmbH 24
Qualitätsmodell Reference Card: "Software Architecture and Quality Essentials" Best practices for developing high quality and low maintenance secure applications Kostenfreier Download auf unserer Website www.hello2morrow.com 2010 hello2morrow GmbH 25
Mögliche Tool Chain Opensource Codehaus Sonar (www.sonarsource.org) als Qualitätsleitstand SonarJ (www.hello2morrow.com) für Architekturprüfung und Strukturüberwachung (Kopplung, Zyklen, Metriken) PMD, Checkstyle und/oder Findbugs für Programmierregeln 2010 hello2morrow GmbH 26
Ihre Fragen Meine Email-Adresse: t.schoen@hello2morrow.com Hello2morrow Aussteller-Stand: Auf der unteren Ebene 2010 hello2morrow GmbH 27