der agile software architekt - berlin-dose.de · presentation domain persistence definition einer...
TRANSCRIPT
![Page 1: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/1.jpg)
Der agile Software Architekt
2013-09-25
Ingmar Kellner
![Page 2: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/2.jpg)
Agil == Beweglich == Zur Handlung Fähig
Gegebene Versprechen schränken meine Agilität ein!
© 2013, hello2morrow GmbH 2
Source: http://de.wiktionary.org/wiki/agil
![Page 3: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/3.jpg)
Architektur
Architecture is the fundamental organization of a system embodied
in its components, their relationships to each other, and to the
environment, and the principles guiding its design and evolution.
[IEEE 1471]
© 2013, hello2morrow GmbH 3
![Page 4: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/4.jpg)
Unser Problem: Strukturelle Erosion
Immobility
Opacity
Rigidity
Fragility
Viscosity
Source: Robert C. Martin
© 2013, hello2morrow GmbH 4
![Page 5: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/5.jpg)
Ursachen
§§ Laws of Software Entropy
Zeitdruck
Fehlende Qualitätsregeln
Unschöne Schnittstellen
Fehlende automatische Überprüfung von Regeln
„Wen kümmert‘s???“ – Mentalität
…
© 2013, hello2morrow GmbH 5
![Page 6: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/6.jpg)
Vertrauen ist gut, Kontrolle ist besser…
© 2013, hello2morrow GmbH 6
“You can’t manage what you can’t control, and you can’t control what
you don’t measure” [Tom DeMarco]
![Page 7: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/7.jpg)
7
Messung des Kopplungsgrades [John Lakos]
Depends upon = Die Anzahl von Komponenten, von der eine
Komponente direkt oder indirekt abhängig ist (+1 für sich selbst)
ACD (Average Component Dependency) = Die Summe aller
“depends upon” Werte geteilt durch die Anzahl von
Komponenten
6
3 3
1 1 1
ACD = 15/6 = 2,5
© 2013, hello2morrow GmbH
3
1 1
2 3 2
Dependency Inversion:
ACD = 12/6 = 2
6
6 6
1 6 1
Zyklen:
ACD = 26/6 = 4,33
![Page 8: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/8.jpg)
Einfluss von Zyklen auf Agilität
© 2013, hello2morrow GmbH 8
Element A
Element B
Element C
Element A
Element B
Element C
1
2
3
Level
![Page 9: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/9.jpg)
Beispiel einer Package-Zyklengruppe
Zyklengruppe von 46 Packages
© 2013, hello2morrow GmbH 9
![Page 10: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/10.jpg)
Auflösen eines Package Zyklus
© 2013, hello2morrow GmbH 10
![Page 11: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/11.jpg)
Dependency Inversion via Callback Interface
© 2013, hello2morrow GmbH 11
![Page 12: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/12.jpg)
Schnittstellen, Schnittstellen, Schnittstellen, …
© 2013, hello2morrow GmbH 12
Geringer
Kopplungsgrad
Mehr Wieder-
verwendung
Aussagekräftige
Schnittstellen Einhaltung von
Schnittstellen
Höhere
Entwicklungs-
geschwindigkeit
Wirtschaftlicher
Erfolg
Realisierung von
Innovationen
![Page 13: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/13.jpg)
© 2013, hello2morrow GmbH 13
Presentation
Domain
Persistence
Definition einer Architektur Blaupause
Schritt 1: Definition von technischen Abstraktionen
Schritt 2: Definition von fachlichen Abstraktionen
Con
tract
Custo
me
r
User
Co
mm
on
Schritt 3: Definition von Schnittstellen
Software System
Schritt 4: Definition von Abhängigkeiten
Schritt 5: Verbindung zum Source Code
![Page 14: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/14.jpg)
Qualitätsbewusstsein
Kontrolle der Abhängigkeiten
Definition von Regeln
Namenskonventionen
Automatisierte Überprüfung
Werkzeuge
Infrastruktur (z.B. OSGi)
© 2013, hello2morrow GmbH 14
![Page 15: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/15.jpg)
Architektur in der Agilen Entwicklung
© 2013, hello2morrow GmbH 15
Definiert die Architektur,
Metriken + Schwellenwerte,
identifiziert „hot spots“
Implementiert Use Cases
unter Berücksichtigung
der Architektur und
Richtlinien
Überprüft kontinuierlich die
Einhaltung der Architektur
und Richtlinien
Rolle “Architekt” Rolle “Entwickler”
Build Server
![Page 16: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/16.jpg)
Positive Effekte
Barry M. Horowitz, DoD Study
© 2013, hello2morrow GmbH 16
![Page 17: Der agile Software Architekt - berlin-dose.de · Presentation Domain Persistence Definition einer Architektur Blaupause Schritt 1: Definition von technischen Abstraktionen Schritt](https://reader033.vdocuments.pub/reader033/viewer/2022052002/60154eec7a2f0a70c51876fa/html5/thumbnails/17.jpg)
Weitere Informationen
Whitepapers, DZone RefCard, etc. auf unserer Web-Seite:
http://www.hello2morrow.com
Referenzen:
Applying UML And Patterns, Craig Larman, Prentice Hall 2000
Agile Software Development, Robert C. Martin, Prentice Hall 2003
Large-Scale C++ Software Design, John Lakos, Addison-Wesley 1996
Design Patterns, Gamma et al., Addison-Wesley 1994
Controlling Software Projects: Management, Measurement, and Estimates, Tom DeMarco,
Prentice Hall, 1982
The Mythtical Man Month, Frederick P. Brooks, Addison-Wesley, 1975, 1995
The Pragmatic Programmer: From Journeyman to Master, Andrew Hunt, David Thomas,
Addison-Wesley, 1999
© 2013, hello2morrow GmbH 17