Agile Architektur - OIO · 2020. 8. 27. · Agiles Manifest = Individuen und Interaktionen mehr als...

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

Agile Architektur

1.0

Agile Architektur© Orientation in Objects GmbH

Abstract

2

Eine gut geplante Softwarearchitektur stellt das Grundgerüst jederwartbaren Software dar. Das steht in einem scheinbaren Widerspruch zuagilen Softwareprozessen, bei denen langfristige Planungenweitestgehend vermieden werden.

Die Session zeigt anhand zahlreicher konkreter Beispiele, wie man dieErstellung einer Softwarearchitektur in einzelne Aufgabenpaketeunterteilt, dokumentiert und regelmäßig durch Reviews undautomatisierte Architekturtests verifiziert. Das Ziel ist es, auch in einemiterativen Prozess eine langfristig tragfähige Architektur entstehen zulassen.

2


Ihre Sprecher

Trainer, Berater, Entwickler

3

Thorsten Maier, Falk Sippach

@ThorstenMaier @sippsack

Agile Architektur© Orientation in Objects GmbH 4

Agiles Manifest=

Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Funktionierende Software mehr als umfassende Dokumentation

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Reagieren auf Veränderung mehr als das Befolgen eines Plans

3


Architektur

"Strukturen eines Softwaresystems:

Softwareteile, die Beziehungen zwischen

diesen und die Eigenschaften der

Softwareteile und ihrer Beziehungen"

(Paul Clements)


Architektur in eigenen Worten:

fundamentale Strukturen,

Konzepte,

Entscheidungen

und Lösungsansätze

... die man nicht mehr leicht los bekommt!

4


Agile Architektur

Widerspruch?


Unsere These

Eine gute Architektur kann iterativ in kleinen

Aufgabenpaketen entstehen.

5


Agiles Manifest

Die BESTEN Architekturen […] entstehen

durch selbstorganisierte Teams.

(11. Prinzip der agilen Softwareentwicklung)


6


Herausforderung in einem agilen Prozess

Architekturarbeit aufteilen

Darum geht es heute

15 konkrete Arbeitspakete


ArchitekturArchitekturArchitekturArchitektur

entwerfenentwerfenentwerfenentwerfen


umsetzenumsetzenumsetzenumsetzen

automatischautomatischautomatischautomatisch

prüfenprüfenprüfenprüfen

Prozess & ArchitekturProzess & ArchitekturProzess & ArchitekturProzess & Architektur

verbessernverbessernverbessernverbessern

7


1

13

Nicht-funktionale

Anforderungen konkretisieren

� Software-Architektur


„Benutzerfreundlich“

„Schnell“

„Wartbar“

8


Nicht-funktionale Anforderungen

müssen prüfbar sein


„Benutzerfreundlich“

=

Nachbearbeitung eines Inkasso-Anrufes

darf maximal 30 Sekunden dauern und muss

nach 3 Klicks abgeschlossen sein.

9


„Schnell“

=

Synchrone Anfragen < 1000ms

Benachrichtigung bei asynchronen Anfragen

Falls Anfrage > 200ms � Ladeanimation


„Wartbar“

=

Ein neues Krankenversicherungsprodukt lässt

sich mit einem durchschnittlichen Aufwand von

28 Personentagen in die Anwendung integrieren.

10


Leitung Entwicklung

19

Marketing

Leitung WartungKunde

Endbenutzer

Stakeholder

bewusst machen

2


Leitung Entwicklung

20

Marketing

Leitung WartungKunde

Endbenutzer

Wartbarkeit

Geringe Kosten,

geringe Fluktuation

Geringe Kosten,

pünktliche Lieferung

Neue Feature

Time-to-market

Schnell,

benutzerfreundlich

Agiles Team

11


Bausteine und deren

Beziehungen entwerfen

3


Fachliche

Spezifikation

Randbedingungen

Qualitätsziele

Architektur

Bau-

steineSpezial-

konzepte

Techno-

logien

Lösungsstrategie

Risi-

ken

12


Architektur bewerten

4


Theorie:

Architekturen früh vergleichbar

Praxis:

Analyse wird während Schadensbegrenzung

spät im Projekt durchgeführt

13


Szenariobasierte

Architekturbewertung

SAAM – Software architecture analysis method

ATAM – Architecture tradeoff analysis method

ACDM – Architecture-centric design method


(1) Szenarien erheben und priorisieren

(2) Erstellen der Architektur(en)

(3) Bewertung aus dem Blickwinkel der Szenarien

14


Architektur 1 Architektur 2

Neues Krankenversicherungsprodukt

DHL statt Hermes

…

Ergebnis

Komponenten Aufwand Komponenten Aufwand

3 28d 2 20d

- - 4 12d

3 28d 6 32d

Stakeholder


Architektur dokumentieren

5

15


Ansicht

Schnitt

Grundriss


Kontextsichten

Laufzeitsichten Bausteinsichten Verteilungssichten

16


Lev

el

0Le

ve

l 1

Lev

el

2

Nicht zu detailliert,

sondern pragmatisch

und effizient!


Templates für:

Microsoft Word

Confluence

Markdown, AsciiDoc

Latex, DocBook

HTML, EPUB

Textile

17


Continuous

Documentation

Documentation

as Code

REPO


HTML,

PDF, …

Leser

EntwicklerDokumentation als

Plain Text

18


Architektur kommunizieren

6


"Man glaubt nur so lange, dass

ein Entwurf perfekt ist, bis man ihn

jemand anderem gezeigt hat."

(Software Architecture Documentation in Practice von Bachmann, Bass)

19


vs.

ԪԬ

$€!!!!

?


Wenn man die Architektur

nicht erklären kann,

ist sie zu kompliziert!

20











21


Abstraktionen entwerfen

7


UserController

22


CRUDController

UserController …


CRUDController

UserController

ReadController

…

…

23


CRUDController

UserController

ReadController

CRUDButNotDeleteController

…

…


UserCreateController

CreateController

UserReadController

ReadController

UserUpdateController

UpdateController

24


Querschnittsaspekte behandeln

8


Logging

Security

Transaktionen

Monitoring

8a

8b

8c

8dSpezialkonzept

25


Dokumentation generieren

9


interface DemoService {String foobar();

}

class DemoServiceImpl implements DemoService {@Overridepublic String foobar() {

return "demo";}

}

enum State {NEW, OPEN, APPROVED, IN_PROGRESS, FIXED

}

50

PlantUML +

AsciiDoc

generieren

Quellcode

DB-Schema

UML-Modell

Konfiguration

@startuml

interface DemoServiceDemoService <|-- DemoServiceImpl

enum State {NEWOPENAPPROVEDIN_PROGRESSFIXED

}

@enduml

# Werte von State

* NEW* OPEN* APPROVED* IN_PROGRESS* FIXED

26


Generate

automatisiert

validieren!










27


Automatisierte

Architekturchecks

10


28


Controller

ServiceImpl


https://github.com/thorstenmaier/architecture-layer-check/

Controller

ServiceImpl

DaoImpl

29



(Service) - [DEPENDS_ON] -> (Controller)

30


MATCH (s:Service)-[:DEPENDS_ON]->(c:Controller) return s,c


31


Dokumentation ausführen

11


32



Living Documentation

33


Architektur-

definition

in PlantUML

Generierte

Cypher-

Regel

[[architecture:DefinedDependencies][plantuml,role=concept]----[artifactId:xo.impl] as impl <<:Maven:Project>>[artifactId:xo.api] as api <<:Maven:Project>>[artifactId:xo.spi] as spi <<:Maven:Project>>

impl -> api : Defines Dependencyimpl -> spi : Defines Dependencyspi -> api : Defines Dependency----

[[architecture:UndefinedDependencies[source,cypher,role=constraint,requiresConceptsThere must not be dependencies between Maven project which have not been defined.----MATCH(p1:Maven:Project)-[:CREATES]-(p2:Maven:Project)-[:CREATES]-(t2)-[:DEPENDS_ON]->(t1)

WHERE NOT(p1)-[:DEFINES_DEPENDENCY

RETURN*

----


Code Reviews

12

34


Kennen Sie das?

„Das ist historisch

gewachsen.“


…noch ein Klassiker

„Thomas ist leider gerade

im Urlaub“

35


Neben den automatisierten Checks benötigen

wir auch menschliche Checks

Code-Reviewsals kontinuierliche QS-Maßnahme


Bugs finden

36


Wissen


100 105

15

0

20

40

60

80

100

120

ohne Code-Review mit Code-Review

En

twic

klu

ng

sko

ste

n i

n %

Code-Review

Entwicklung

37


ohne Code-Review mit Code-Review

Bugfixing

Code-Review

EntwicklungWissen


Jeder mit jedem!

38


200 – 400 Zeilen

1 – 2 Stunden

http://support.smartbear.com/resources/cc/book/code-review-cisco-case-study.pdf

Dauer des Reviews

Gefundene

Fehler


39











Retrospektive

durchführen

13

40


Entwicklungsteam Management KundeArchitektur


Verbesserungen einplanen

14

41


Arbeitspakete

aus Retrospektive


Verbesserungen

vorantreiben

15

42


Something that's

everybody's responsibility

is no one's responsibility.


Mitentwickelnder

Kümmerer/

Koordinator

43










Nicht-funktionale

Anforderungen

konkretisieren

Stakeholder

bewusst machen

Bausteine und deren

Beziehungen

entwerfen Bewerten

Dokumentieren

Kommunizieren

Querschnittsaspekte

behandeln

Automatisierte

Architekturtests

Code

Reviews

Retrospektive

durchführen

Verbesserungen

einplanen

Verbesserungen

vorantreiben

Abstraktionen

entwerfen

Dokumentation

generieren

Dokumentation

ausführen










Nicht-funktionale

Anforderungen

konkretisieren

Stakeholder

bewusst machen

Bausteine und deren

Beziehungen

entwerfen Bewerten

Dokumentieren

Kommunizieren

Querschnittsaspekte

behandeln

Automatisierte

Architekturtests

Code

Reviews

Retrospektive

durchführen

Verbesserungen

einplanen

Verbesserungen

vorantreiben

Abstraktionen

entwerfen

Dokumentation

generieren

Dokumentation

ausführen

Thorsten

ThorstenThorsten

Thorsten

Thorsten

Thorsten

Thorsten

Thorsten

Falk

Falk

Falk

Falk

Falk

Falk

Falk

44

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]

Vielen Dank für Ihre Aufmerksamkeit!

Date post:	05-Sep-2020
Category:	Documents
Upload:	others
View:	1 times
Download:	0 times

Agile Architektur - OIO · 2020. 8. 27. · Agiles Manifest = Individuen und Interaktionen mehr als...

Documents