agile architektur - oio.de · 2 © orientation in objects gmbh agile architektur ihre sprecher...

1

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]:

Agile Architektur

1.1

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 in eigenen Worten:

fundamentale Strukturen,

Konzepte,

Entscheidungen

und Lösungsansätze

... die man nicht mehr leicht los bekommt!


Agile Architektur

Widerspruch?

4


Unsere These

Eine gute Architektur kann iterativ in kleinen

Aufgabenpaketen entstehen.


Agiles Manifest

Die BESTEN Architekturen […] entstehen

durch selbstorganisierte Teams.

(11. Prinzip der agilen Softwareentwicklung)

5


Herausforderung in einem agilen Prozess

Architekturarbeit aufteilen

Darum geht es heute

12 konkrete Arbeitspakete


PLANPLANPLANPLAN

DODODODO

CHECKCHECKCHECKCHECK

ACTACTACTACT

6


ArchitekturArchitekturArchitekturArchitektur

entwerfenentwerfenentwerfenentwerfen


umsetzenumsetzenumsetzenumsetzen

automatischautomatischautomatischautomatisch

prüfenprüfenprüfenprüfen

Prozess & ArchitekturProzess & ArchitekturProzess & ArchitekturProzess & Architektur

verbessernverbessernverbessernverbessern


1

12

Nicht-funktionale

Anforderungen konkretisieren

� Software-Architektur

7


„Benutzerfreundlich“

„Schnell“

„Wartbar“


Nicht-funktionale Anforderungen

müssen prüfbar sein

8


„Benutzerfreundlich“

=

Nachbearbeitung eines Inkasso-Anrufes

darf maximal 30 Sekunden dauern und muss

nach 3 Klicks abgeschlossen sein.


„Wartbar“

=

Ein neues Krankenversicherungsprodukt lässt

sich mit einem durchschnittlichen Aufwand von

28 Personentagen in die Anwendung integrieren.

9


Leitung Entwicklung

17

Marketing

Leitung WartungKunde

Endbenutzer

Stakeholder

bewusst machen

2


Leitung Entwicklung

18

Marketing

Leitung WartungKunde

Endbenutzer

Wartbarkeit

Geringe Kosten,

geringe Fluktuation

Geringe Kosten,

pünktliche Lieferung

Neue Feature

Time-to-market

Schnell,

benutzerfreundlich

Agiles Team

10


Bausteine und

Beziehungen entwerfen

3


Fachliche

Anforderungen

Randbedingungen

Qualitätsziele

Architektur

Bau-

steineSpezial-

konzepte

Techno-

logien

Lösungsstrategie

Risi-

ken

11


Architektur bewerten

4


Theorie:

Architekturen früh vergleichbar

Praxis:

Analyse wird während Schadensbegrenzung

spät im Projekt durchgeführt

12


Szenariobasierte

Architekturbewertung

SAAM – Software architecture analysis method

ATAM – Architecture tradeoff analysis method

ACDM – Architecture-centric design method


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

13


Architektur dokumentieren

5


Ansicht

Schnitt

Grundriss

14


Kontextsichten

Laufzeitsichten Bausteinsichten Verteilungssichten


Lev

el

0Le

ve

l 1

Lev

el

2

Nicht zu detailliert,

sondern pragmatisch

und effizient!

15


Templates für:

Microsoft Word

Confluence

Markdown, AsciiDoc

Latex, DocBook

HTML, EPUB

Textile


Continuous

Documentation

Documentation

as Code

REPO

16


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)

17


vs.

ԪԬ

$€!!!!

?


Wenn man die Architektur

nicht erklären kann,

ist sie zu kompliziert!

18











19


Dokumentation generieren

7


interface DemoService {String foobar();

}

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

return "demo";}

}

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

}

38

PlantUML +

AsciiDoc

generieren

Quellcode

DB-Schema

UML-Modell

Schnittstellen

Konfiguration

@startuml

interface DemoServiceDemoService <|-- DemoServiceImpl

enum State {NEWOPENAPPROVEDIN_PROGRESSFIXED

}

@enduml

# Werte von State

* NEW* OPEN* APPROVED* IN_PROGRESS* FIXED

20


Generate

automatisiert

validieren!










21


Automatisierte

Architekturchecks

einrichten

8


@Component

public class DemoServiceImpl implements DemoService {

@Autowired

private DemoController demoController;

public void superServiceMethod() {

demoController.doSomething();

}

}

42

Controller

ServiceImpl

22


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

Controller

ServiceImpl

DaoImpl

@RunWith(SpringRunner.class)

@SpringBootTest

public class DepencencyTesterApplicationTests {

@Autowired

private DefaultListableBeanFactory beanFactory;

@Test

public void checkDependencies() {

for (String beanName : beanFactory.getBeanDefinitionNames()) {

for (String depName : beanFactory.getDependenciesForBean(beanName)) {

checkNotAllowedConnection(beanName, depName, ".*ServiceImpl", ".*Controller");

checkNotAllowedConnection(beanName, depName, ".*Controller", ".*DaoImpl");

checkNotAllowedConnection(beanName, depName, ".*DaoImpl", ".*Controller");

}

}

}

private void checkNotAllowedConnection(String beanName, String depName, String beanNamePattern,

String dependencyNamePattern) {

String msg = "Connection not allowed: " + beanName + " -> " + depName;

assertFalse(msg, beanName.matches(beanNamePattern) && depName.matches(dependencyNamePattern));

}

}


Dokumentation ausführen

9

23


Living Documentation


24


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

installieren

10

25


Kennen Sie das?

„Das ist historisch

gewachsen.“


…noch ein Klassiker

„Thomas ist leider gerade

im Urlaub“

26


Bugs finden


Wissen

27


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


ohne Code-Review mit Code-Review

Bugfixing

Code-Review

EntwicklungWissen

28











Retrospektive

durchführen

11

29


Entwicklungsteam Management KundeArchitektur


Verbesserungen einplanen

und vorantreiben

12

30


Arbeitspakete

aus Retrospektive


Something that's

everybody's responsibility

is no one's responsibility.

31


Mitentwickelnder

Kümmerer/

Koordinator










Nicht-funktionale

Anforderungen

konkretisieren

Stakeholder

bewusst machen

Bausteine und

Beziehungen

entwerfen

Architektur

bewerten

Architektur

dokumentieren

Architektur

kommunizieren

Automatisierte

Architekturtests

einrichtenCode Reviews

installieren

Retrospektive

durchführen

Verbesserungen

einplanen und

vorantreiben

Dokumentation

generieren

Dokumentation

ausführen

32










Nicht-funktionale

Anforderungen

konkretisieren

Stakeholder

bewusst machen

Bausteine und

Beziehungen

entwerfenArchitektur

bewerten

Architektur

dokumentieren

Architektur

kommunizieren

Automatisierte

Architekturtests

einrichten

Code Reviews

installieren

Retrospektive

durchführen

Verbesserungen

einplanen und

vorantreiben

Dokumentation

generieren

Dokumentation

ausführen

Thorsten

Thorsten Thorsten

Thorsten

Thorsten

Thorsten

Falk

Falk

Falk

Falk

Falk

Falk

Orientation in Objects GmbH

Weinheimer Str. 6868309 Mannheim

[email protected]

Vielen Dank für Ihre Aufmerksamkeit!

agile architektur - oio.de · 2 © orientation in objects gmbh agile architektur ihre sprecher...

Documents